Ramp MCP

Activates an unactivated card for the user. If the card is a physical card awaiting delivery confirmation, call this tool first without confirm_delivery to detect the state, then call again with confirm_delivery=True after the user confirms the physical card has arrived.

Compatibility route for callers that have not migrated to SetTravelerLoyaltyProgram

Provide user_email for a human or agent_id for a standalone agent; role defaults to MEMBER.

Returns active agent-managed account numbers and all payment details available for receiving funds.

Use this tool when the user asks about expense policy rules, spending limits, fund restrictions, or whether certain purchases are allowed under company policy.

Results are sorted by estimated cost in descending order, then by API key ID in ascending order. A request can match at most 10,000 API keys. Use the providers or statuses filter to narrow larger result sets. Estimated cost is calculated for the requested period. All other fields reflect current metadata for the API key, independent of the requested dates. The statuses filter applies to each API key's current status.

The authenticated user must be the next required approver on the bill's approval chain. Rejection is additionally allowed for bill-pay admins as an override, even when they are not the next approver. Find bills awaiting the authenticated user's approval with get-bills-for-approval. Some bills require step-up verification that agents cannot complete; in that case the error includes a redirect_url that the human user must open in a browser to finish the action there. Approving advances the bill's approval chain, exactly as approving in the Ramp web app does: depending on the business's payment-release settings, a bill that becomes fully approved with payment details and a payment date already set may proceed to payment automatically. After an approval, the response reports the bill's resulting payment state: whether any of its payments has been initiated (payment_initiated — this includes earlier partial payments; a chain-completing approval may have just added one) and the earliest such payment date (payment_date) — so you can inform the user. This tool never schedules payments or edits payment details; payment scheduling and release are managed in the Ramp web app — hand the user the bill_url returned on success.

Use this tool when the user wants to approve or reject a reimbursement. Reimbursements are employee-submitted requests for reimbursement of out-of-pocket expenses. Common usage patterns: "approve this reimbursement", "reject the expense", "yes, reimburse them", "no, don't reimburse this". This tool is specifically for employee reimbursements and is NOT for approving/rejecting card transactions or unified requests (spend allocations, purchase orders).

Use this tool when a user wants to approve or reject a specific request they have identified or referenced. Common usage patterns: "approve this request", "reject this request", "accept the request", "deny this", "authorize this", "yes approve it", "decline this request". This tool is specifically for unified requests (spend allocations, purchase orders, procurement approvals) and is NOT for approving expenses like corporate card transactions or reimbursements. The user must have proper approval authority for the request.

Use this tool when the user wants to approve a transaction, send it back for revisions, or require the cardholder to repay the full amount. The acting user must have the proper approval authority for the transaction. If the user provides a written justification (e.g., “reject this because the receipt is missing”), pass that verbatim via `user_reason`—do not invent your own rationale.

Archive a fund to prevent spend and hide it from users

closing its current RFX. Prerequisites: grading must be complete on the current RFX, the event must not already be awarded or pending award approval, and the payee must be an active invited vendor on the RFX. When the business configures an award approval policy, the award routes through that approval workflow instead of awarding immediately (``submitted_for_approval`` is True and nothing is decided yet). After a direct award, use CreateDraftSpendRequestFromSourcingEvent to hand off into procurement.

Cancel the payment on a reimbursement that has been approved but not yet paid out

Closing cascades to every non-terminal child RFX: each is transitioned to CLOSED, which blocks further vendor submissions and grading and voids any outstanding e-sign envelopes. Closed events are hidden from default list views and become read-only. Use AwardSourcingEvent instead when a winning vendor should be selected.

Use this after the cardholder has addressed the requested changes and explicitly asks to mark the transaction revision complete. The completion refreshes the corresponding task and starts Task Platform's sanction-lifting workflow.

Department names are unique within the business (case-insensitive). If a department with the requested name already exists, it is returned instead of creating a duplicate.

Returns the draft UUID, initial version, and Ramp URL. This does not start approval, schedule, release, or initiate payment. Omitted fields remain empty, so the new draft may not yet be ready for submission.

spend request pre-filled with the winning vendor's context. The draft is prefilled from the sourcing conversation, event details, and (when ``rfx_id`` is passed) the awarded vendor's RFX responses. The user reviews and submits the draft in procurement. ``payee_uuid`` defaults to the awarded vendor and ``spend_intent_uuid`` defaults to the backend's recommended spend program when omitted. This call runs LLM extraction and can take a while.

Always use this tool (never invent URLs) and include the returned url in your next message. Prefer spend-program request tools first when available; use this for one-off/default funds or when no program fits. Infer fields from context; do not ask for more details unless the user asks.

Call SearchVendors first with include_draft=true. Reuse a suitable existing vendor, including a pending vendor, instead of creating a duplicate. Never create a duplicate to work around an existing vendor whose status is INACTIVE — an admin must re-enable that vendor instead. A vendor contact email is required; contact names are optional.

Pass amount/currency_code/transaction_date/merchant to skip OCR.

event in the same call. Nothing is sent to vendors until the RFX is published. Use GetRFXDetail to review the created questionnaire and InviteVendorsToRFX to add vendors before publishing.

Do not call this solely as a prerequisite for booking a flight or hotel; SubmitFlightBooking and SubmitHotelBooking automatically select or create a trip when trip_id is omitted. If the user explicitly asks to create a named trip in addition to booking, call this once and pass the returned trip_uuid as trip_id to every related SubmitFlightBooking and SubmitHotelBooking call.

Delete an abandoned procurement draft owned by the acting user

Deletion is permanent and only allowed for reimbursements the acting user is permitted to delete (their own drafts, or others' if they have write access). Reimbursements that have progressed too far in the payment lifecycle cannot be deleted; use CancelReimbursementPayment for approved-but-unpaid reimbursements.

Use this tool when an admin wants to permanently delete a spend program. If the program has linked funds (spend allocations), the caller must specify what to do with them via spend_intent_delete_action: - "terminate": Close all linked funds. - "transfer": Move funds to another spend program (requires transfer_to_spend_intent_uuid). - "detach": Unlink funds from the program but keep them active. - "bulk_lock": Lock all cards associated with linked funds (admin only). If the program has no linked funds, spend_intent_delete_action can be omitted.

Returns the departments available in the user's business, which can be used as inputs to workflows that require department references. Each department includes organizational metadata: its owners (managers), active member count, and managing external firm, if any.

Creates a wire drawdown request from an external bank account. The request may require approval, and funds arrive only if the external bank fulfills it. Requires an `X-Idempotency-Key` header.

Duplicate an existing reimbursement as a new draft

Omitted fields stay unchanged; null/[] clear when editable.

Returns the updated transaction, remaining missing items, and a transaction_link for fields the API cannot edit.

Change a shared-fund user's role between member and co-owner using user_email

Use this when a user wants to turn an existing personal fund into a shared fund, or when adding a member requires sharing to be enabled first.

Enroll the current business in agent cards for agentic commerce

Estimate the reimbursement amount for a given mileage distance based on the user's company rates

Estimate the per diem reimbursement amount for a trip given start/end dates and optional meal deductions

Get audit log events

First use the analyst catalog and read the domain docs for every table in the query; those docs define supported tables, columns, joins, and metric semantics.

Before calling, use ListBusinessAccounts to obtain the source account UUID; never guess it. Confirm the exact source account and positive USD amount with the user before creating this irreversible transfer. MCP and CLI callers must provide an idempotency key. Only active Increase USD accounts are supported.

Use when the user asks about balance history for a specific account, savings account trend, checking account balance over time, or the balance trend for a specific Ramp Checking Account. This tool only supports Ramp Checking Accounts, not Investment Accounts or Managed Portfolios.

Handles card enrollment and purchase instructions automatically.

Returns eligible funds with available balance.

Aggregate AI token usage or estimated cost over a time window, grouped by caller-selected dimensions (provider, model, configuration, department, user, or API-key tag group)

Use GetAiTokenSpendCurrentSpend for actual vendor spend and GetAiTokenSpendAggregates for estimated token usage and cost.

Requires transaction, reimbursement, or bill read access.

List the dimensions and values available for AI-spend aggregate queries: providers, models, model families/facets, departments, and API-key tag groups

Review the catalog before writing a query, then read domain docs for every table used.

Discover supported analyst metrics and starter SQL for aggregate business analysis

Read domain documentation for analyst.spend_facts before using it in an analyst query

Read domain documentation for an analyst table before using it in an analyst query

Use this tool to see what needs the user's attention right now: pending approvals, missing receipts, overdue reviews, signatures, and similar action items that appear on the Ramp homepage. By default, the tool returns the default homepage sections with compact LIST-hydrated task rows. To fetch more from a section, pass that section's section_type and next_cursor back in sections. For own-card GET_ATTENTION_FEED remediation, use this as the canonical task feed. blocking_effects describes a task type's possible sanction, not proof that an item caused the active lock. Use browser_handoff for user action in Ramp. For an available CompleteTransactionRevision, inspect or edit the transaction and call it with a nonblank reason. Re-read both tools and continue relevant overdue tasks; success requires the task absent, blocking_task_count=0, and is_spendable=true. Pending verification is not an unlock.

This tool returns all client businesses that the external firm (advisor console) user has been granted access to. Use this to understand which businesses the user can work with or to help them find a specific client. Supports filtering by business display name and pagination for large lists.

List bank accounts

Examples: total unpaid amount, total pending amount. Use when users ask things like "How much do we owe in bills?" or "What's our total outstanding bill amount?". Bills in Ramp have two stages: draft bills (created/uploaded but not yet submitted; use the draft-bill tools) and bills (submitted; they move through approval, then scheduling, then payment). A draft keeps the same ID after submission, but draft-only tools stop working on it once submitted.

Bills in Ramp have two stages: draft bills (created/uploaded but not yet submitted; use the draft-bill tools) and bills (submitted; they move through approval, then scheduling, then payment). A draft keeps the same ID after submission, but draft-only tools stop working on it once submitted.

Requires a bill UUID and known submitted status. A UUID alone does not establish submission: a draft keeps the same UUID after submission. Not applicable to bills whose draft/submitted stage is unknown or to unsubmitted drafts. Returns bill metadata, payment status, and approval status. Submitted bills include bills awaiting approval, scheduling, or payment.

Returns a chronological event log — creation, submission, each approval-chain action with actor and timestamp, and deletion. Use it to answer questions like "who approved this bill?". Bills in Ramp have two stages: draft bills (created/uploaded but not yet submitted; use the draft-bill tools) and bills (submitted; they move through approval, then scheduling, then payment). A draft keeps the same ID after submission, but draft-only tools stop working on it once submitted.

Returns the source documents backing the bill: for each attachment, the filename, type, and a time-limited download URL (the URL expires after about 3 days). Draft bills are not supported: draft attachments are not retrievable through agent tools. get-draft-bill-details returns draft metadata and a link to the draft page in the Ramp web app, where attachments can be viewed. Bills in Ramp have two stages: draft bills (created/uploaded but not yet submitted; use the draft-bill tools) and bills (submitted; they move through approval, then scheduling, then payment). A draft keeps the same ID after submission, but draft-only tools stop working on it once submitted.

Use this to answer questions like "How many bills are pending approval?" or "How many overdue bills do we have?". Bills in Ramp have two stages: draft bills (created/uploaded but not yet submitted; use the draft-bill tools) and bills (submitted; they move through approval, then scheduling, then payment). A draft keeps the same ID after submission, but draft-only tools stop working on it once submitted.

Use this tool when the user wants to see bills they need to approve or asks about pending approvals. This returns only bills where the authenticated user is the next required approver in the approval chain. Bills in Ramp have two stages: draft bills (created/uploaded but not yet submitted; use the draft-bill tools) and bills (submitted; they move through approval, then scheduling, then payment). A draft keeps the same ID after submission, but draft-only tools stop working on it once submitted.