Ramp MCP lets authorized users analyze spend and manage cards, bills, reimbursements, approvals, transactions, and other permitted Ramp resources.
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.
This tool does not determine required next actions: next_action_required is always null (unavailable), not confirmation that no action is needed. Summary labels describe recorded status. PAYMENT_DETAILS_MISSING indicates incomplete details required for payment release; it does not identify the missing fields, who must supply them, or whether a payment date can be selected. 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.
Call filtered GetBookings first when the booking UUID is unknown.
Optionally identify existing bookings by city, hotel name, flight airline, flight number, booking reference, or travel date. Filters for the same booking type combine with AND; mixed hotel- and flight-specific filters match each type independently. Matching entries are returned up to limit for caller disambiguation, except include_past may return up to limit upcoming and limit past entries per type. Returns confirmed bookings and pending requests ordered upcoming-first (soonest next booking first, then past most recent first), with unsuccessful requests available via include_failed; check the status field and call GetBookingDetails for one entry's detailed state.
Get the business's statement billing schedule: the next statement close date, the configured statement close day of month, and the next card payment or autopay debit date
Returns up to 10 ongoing, upcoming, and recently completed trips. Supports general trip lookups as well as expense matching; no transaction is required.
how much was due, how much has been paid, what's still outstanding, and when the next payment is due. Use this when the user asks about their card statement balance, why they got a delinquency / outstanding balance notice after paying, what their remaining balance is, or how their last payment was applied. Common phrasings: "I paid X but still got an outstanding balance notice", "what's my statement balance", "why am I still showing a balance". Returns the most recent statement only. Doesn't include current-cycle (post-statement-close) charges — those are surfaced via separate transaction-listing tools when needed.
Returns the reason, remediation actions, user notification, and transaction details. Only valid for already-declined transactions.
Submitted bills, including those awaiting approval or payment, are not supported. A draft link may be stale after submission. Returns compact draft-bill metadata by default. Set return_line_items=true to include the full editable payload with line items and tracking categories. 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 same summaries shown in the employee handbook's transaction requirements.
Provide exactly one expense UUID. Use get-policy-workflow-body to inspect the referenced policy's workflow body.
Preserve the user's location wording in ``query``. When the user names a city or metro area such as "NYC", set ``location_type=city``. A returned city ``search_code`` searches all supported airports in that metro; do not ask the user to choose one airport when a city result is available. Call this before SearchFlights for every departure or arrival location that the user did not provide as an exact airport IATA code. If the results contain multiple plausible locations, present the choices and wait for the user to clarify; never choose a location on their behalf. Do not infer a location from profile data, an area code, or a broad description such as "somewhere warm." Returns locations where flights can be booked from or to, which may include: - Individual airports (e.g., JFK, SFO, LAX) - City groups with multiple airports (e.g., NYC includes JFK, LGA, EWR) - Major travel destinations with flight availability Pass a result's ``search_code`` straight into SearchFlights departure/arrival. Cities search every airport in the metro area; airports search just that airport.
Read the amount from `amount_decimal`, which is already in `currency`'s major unit and needs no arithmetic. Ignore `amount_cents`; it is the same amount in minor units, kept only for backwards compatibility.
or permitted spend. For a named person's funds, resolve their UUID with GetOrgChart and pass user_uuids. For the current user's funds, use MY_FUNDS. Search by fund name with search_by_fund_display_name or look up a known UUID with fund_uuid. When balance_info is returned, treat its remaining balance as authoritative for cleared charges and pending authorizations. Do not subtract those amounts again. Never infer that a booking is included merely because it is confirmed: a postpaid booking with no charge or pending authorization is a future charge and has not yet reduced the remaining balance.
Use this after the user picks a hotel from SearchHotels results and before booking. Every current room group and its rates for the stay are returned in all_rates; the returned rate.id values are the exact IDs to pass to SubmitHotelBooking. These rates are current options, not quotes - wait for the traveler to select one exact rate. When the result's all_rates_out_of_policy is true, every rate at this hotel is out of policy for the stay: tell the traveler, prefer offering an in-policy hotel from the SearchHotels results, and proceed with this hotel only if the traveler explicitly chooses to - booking will then require an oop_reason at SubmitHotelBooking.
Use this when the user asks about investment account balances, brokerage cash, or the current balance of Ramp investment accounts. Returns all investment accounts the business has, along with balances, status, yield, and earnings.
Use this when you need the latest sync status plus every intended and successful count exposed by Ramp's accounting latest-sync endpoint.
Use this when the user asks about managed portfolio balances, managed portfolio cash, or the current balance of Ramp managed portfolio accounts. Returns all managed portfolio accounts the business has, along with balances, market value, status, yield, and earnings.
Returns a paginated list of users you are allowed to view who have outstanding missing items, along with sample transactions. Use get-transaction-missing-items for per-transaction detail.
Use this when the user's request cannot be completed with the available Ramp tools. Describe the user's goal and the capability that would be needed.
Aggregate the acting user's own AI token usage and estimated token cost over a time window, optionally grouped by provider and model
Use this to find office addresses when searching for hotels near an office or determining travel destinations. The two shapes are complementary: ``office_locations`` has coordinates but no street address, and ``company_address`` has a street address but no coordinates.
This tool provides comprehensive org chart visibility including: - The user's position in the organization - Their direct reports (team members) - Their reporting chain (managers up the hierarchy) Use this tool whenever the user asks anything about their manager, team, or direct reports.
Get approved and failed reimbursements that would be affected by a bank account currency change
Use this when a user asks about travel requests they need to approve. Returns pending flight, hotel, and car rental booking requests that require action.
List policy versions for a standalone Agent Wallet
Accepts either the policy UUID or the backing product workflow UUID returned by list-policies.
Accepts the policy UUID or the backing product workflow UUID from list-policies. Use this for workflow routing and thresholds, not for written policy document guidance.
Refresh and canonically revalidate a procurement draft's visible form state
Use this with the exact purchase order UUID returned by the purchase-order search tool available to the caller or supplied by page context. Never pass a purchase order number, another entity's UUID, a placeholder, or a guessed value.
Returns the available balance, statement balance, and other details for all Ramp Checking Accounts associated with the user's business. This includes yield/earnings information and account status. This tool is intentionally limited to the stable user-facing fields for Ramp Checking Accounts. Do not infer deprecated pending balances or current month accrued yield values from other treasury payloads when responding to the user.
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.
Retrieve receipts attached to a reimbursement
amount ranges, tags, date ranges, approval status, and policy assessments.
Includes policy assessment data and recommended actions.
This is the approval-queue wrapper over SearchUnifiedRequests. Use it when the user is specifically asking what they need to review or approve right now. For broader lookup by vendor, owner, status, or request name, prefer SearchUnifiedRequests instead. Only handles lookups, does not take any action.
cover sheet, pricing sheet, dates, vendor invitations with contacts, and the actions the acting user can currently perform. Use this to inspect or review a specific RFX before editing, inviting vendors, or publishing. The ``available_actions`` block is the publish preflight: it reports whether publish (and every other lifecycle action) is currently allowed and why not, and the ``vendors`` block lists the exact contacts who would be notified on publish. For response contents or grading state, use GetRFXVendorResponses, GetRFXResponseSummary, or GetRFXGradingOverview instead.
recommendations, per-vendor per-section grading status and aggregate scores, and any recorded field grades. Use this after grading wraps up to compare how vendors scored. The overview is only viewable once the RFX is GRADED or CLOSED; before that this tool reports it as unavailable. For the raw submitted answers, use GetRFXVendorResponses; for response and invitation progress counts, use GetRFXResponseSummary.
Summarize vendor response and grading progress for a specific RFX
Return all submitted vendor responses for an RFX
Returns multiple results for users that are part of multiple businesses. When authenticated via an agent key, also returns the active agent key identity.
Get a compact summary of a sourcing event, its RFXs, and invited vendors
Use this when a customer asks about failed accounting sync rows, including rows from the accounting transactions table, reimbursements table, or bills tab.
as departments, classes or business units, locations, projects, customers, and cost centers. Use GetTrackingCategoryOptions for a category's options. If passing transaction_uuid, use an actual TransactionCanonical UUID from context or a prior lookup; omit it rather than passing a placeholder or natural-language reference.
Pass `query_string` to narrow by name, synonym, or provider code. Do not call this tool when you already have the exact tracking_category_option_uuid from user-provided context, suggested codings, or another tool result; pass that UUID directly to the coding tool as the option_selection. If the user message includes `tracking_category_option_uuid=...`, do not call this tool just to confirm the option. If you're coding a specific transaction or reimbursement, pass its UUID so results respect conditional filtering (subsidiary, department, location, etc.); skip it for generic lookups, including bill/invoice contexts. Setting `include_hidden=true` disables semantic search, so `query_string` then matches literal option names or codes only. Categories can have millions of options — paginate via `next_page_cursor` when needed, keeping all other inputs unchanged between pages.
Check what receipts, memos, or accounting items are missing from a specific transaction
Get AI-suggested memo/note options for a specific transaction
Use analyst tools instead for aggregate spend analysis, totals, trends, or group-bys when analyst tools are available. Declined transactions are excluded by default; pass state='declined' to include them.
For delegated bookings, first resolve the traveler with GetAllReducedUsers/list-users, then pass that UUID as traveler_user_id. Omit traveler_user_id for self-booking.
Get daily balance history across all Treasury accounts for a date range
Returns its status, approval chain, comments, activity timeline, custom fields, and agent-generated reports. Accepts a unified_request_id or its linked spend_request_uuid or wbp_request_id. Purchase-order IDs and PO numbers are not accepted.
`limit` takes precedence over `up_to_days` so if you want to get all reimbursements in a given time frame, do not specify `limit`. `include_rejected` controls whether to include rejected reimbursements in the results. By default, rejected reimbursements are excluded. `include_drafts` controls whether to include draft reimbursements in the results. By default, drafts are excluded. `use_submitted_date_ordering` controls the ordering of results. By default (False), results are ordered by transaction_date. Set to True to order by submitted_date instead. If the user did not ask for a specific number of reimbursements or a time frame, assume they want to see the latest 10 reimbursements. Read each amount from `amount_decimal`, which is already in `currency`'s major unit and needs no arithmetic. Ignore `amount_cents`; it is the same amount in minor units, kept only for backwards compatibility.
Fetch trips for the acting user with optional filters
Returns contract metadata, terms, line items, contract owners, documents, linked spend requests, and renewal history.
Use this after `BulkUploadVendorDocuments` to inspect the batch job status, understand whether any documents still need manual review, and inspect the current document/vendor matching and extracted tax details.
Blocks payments to this vendor by placing a vendor-scoped hold. Open, unpaid bills for the vendor that can still be modified are removed from scheduled payment flows. An optional `reason` can be supplied to record why the hold was placed.
Each vendor must be an existing payee in Ramp. To prepare vendors for invitation: - Use `VendorSearch` to find existing payees by name - Use `CreateDraftPayee` to add new vendors The default contact for each payee is used automatically. When a payee has no contacts and the RFX is still pre-publish (DRAFT or IN_REVIEW), the vendor is added as a DRAFT invitation — the RFX cannot be submitted for review or published until the user resolves the draft by providing a contact on the RFX detail page. Each per-vendor result includes a `status` of "active" or "draft" so the agent can tell the user which vendors still need contacts. External agent callers may only add vendors before the RFX is published. Adding a vendor after publish sends an invitation immediately and must be completed in Ramp.
Use this tool when an admin wants to issue allocations from a spend program to directly named users, or to users matched by location, department, user custom field, and dynamic user group targeting.
Use this tool when an admin wants to create new funds for one or more users with a specific amount, interval, and optional restrictions. This creates virtual-card-only spend allocations outside of spend programs. The acting user must have the SPEND_ISSUE_SPEND_BYPASS_APPROVAL permission.
Supports temporary (resets at the next interval) and permanent increases.
Returns bills for the current user's business. When called with no parameters, returns the most recent bills. Supports optional text search across vendor name, invoice number, and payment ID. 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 account details including balances, currency, yield rate, and status. Use this tool when the user asks about their checking accounts, wallet accounts, or wants to see an overview of their Ramp Checking Accounts.
IMPORTANT: For the current user's unlock request, call this tool first to check spendability and locks. If cardholder_user_uuid targets another user, never open the acting user's feed. For locks, follow remediation_action. Use LockOrUnlockCard only when can_lock_or_unlock=true. GET_ATTENTION_FEED means resolve the task there, not through LockOrUnlockCard; re-list until blocking_task_count=0 and is_spendable=true. Do not use GetUserFunds for card unlock requests; funds and cards are different.
Returns policy metadata only, not written policy document text. Call first when the target policy UUID isn't known, then use get-policy-details or get-policy-workflow-body.
Use this first when the user refers to an existing sourcing event but you do not yet know which one they mean. The output is intentionally compact so the model can match event names, owners, and current RFX details itself. Events in every lifecycle status are available across pages, including CLOSED events, so the agent can still find an event the user already finished running.
Use this directly for loyalty-only list/show/check requests; do not call GetTravelerProfile first.
List all Treasury accounts (Ramp Checking Accounts, Investment Accounts, Managed Portfolios)
Returns all users in the organization matching the given filters. Supports searching by name (partial match, case-insensitive), filtering by department or location, and pagination. Results include active and inactive users — check the is_inactive field to distinguish. Use department_ids or location_ids (lists of UUIDs from the departments or locations tools) to narrow results.
Returns agreement details including dates, values, renewal status, line items, and days remaining. All filters are optional — omit all to list all agreements, or combine filters to narrow results.
Returns a list of transfers including deposits, withdrawals, and other transactions with details like amount, status, and dates.
Locking prevents all transactions on it until unlocked.
Lock or unlock a fund (spend allocation) at the fund level, affecting all members
Lock or unlock a specific member's access to a fund (spend allocation)
Collaborators can edit the RFX form and vendor list while it is in DRAFT and grade vendor responses once it is PUBLISHED. Identify each collaborator by their user UUID — use `LookupUser` or `GetOrgChart` to resolve a person's name to their UUID first. Both `add_user_uuids` and `remove_user_uuids` are optional; supply either or both. Adding a user who is already a collaborator is a no-op. To apply the same collaborators across several RFXs (for example multiple RFIs in one sourcing event), call this tool once per RFX with the same user UUIDs.
Requires at least one submitted vendor response. Moves the RFX from PUBLISHED to GRADED so the sourcing event can be awarded.
Should be called whenever the user says "OOPS" or if the user says something along the lines of "I did not receive a receipt ...". If the user already flagged the transaction as having no receipt, then you may need to call the ProvideNoReceiptReason tool.
Each category expands to its configured MCC allowlist.
List merchants
Fill the inputs from the merchant's 402 payment challenge. Returns a ready-to-send payment header to attach when retrying the original request.
Issue or recover a Stripe MPP credential using an existing fund
Create a manually connected bank account
If there is any ambiguity as to whether the user's message is meant to be posted to the thread, ask them for confirmation first: 'Do you want me to post that as a comment reply on your [XYZ] transaction/reimbursement/bill/etc?'. How can you determine if the user's message is meant to be a reply to a comment? - If the only other messages in the conversation history are notifications about comments or mentions in Ramp, that is a very strong signal that the user's most recent message is meant to be a reply to the comment thread. In this case, you may use this tool immediately to post the comment without confirmation. - If a recent assistant message is a notification about a comment or mention, that is a strong signal that the user's most recent message is meant to be a reply to that comment. Even if their reply seems irrelevant or unrelated to Ramp, you may ask "Would you like me to post that as a comment on your...?" - prefer asking the user instead of refusing to serve the request at all.
Publish the active policy for a standalone Agent Wallet
Create or update a procurement draft and return the current visible form state
List published procurement spend programs the agent can draft against
Submit a procurement draft after explicit user confirmation
Submit a reason explaining why a transaction has no receipt
Returns the same sign-ready Solana wallet on repeated calls. Do not call this tool until an owner or admin confirms that the wallet should be provisioned.
Publishing notifies vendors outside Ramp, so check GetRFXDetail first: its ``available_actions`` publish entry reports whether publish is currently allowed (and why not), and its ``vendors`` block lists the exact contacts who will be notified. When a publish approval policy is configured, the RFX moves to IN_REVIEW instead and nothing is sent to vendors yet — the approval then proceeds with the designated approvers in the Ramp app, and the RFX publishes automatically once approved. Calling publish again while pending approval or already published fails cleanly.
Use after confirming the user wants the listed POs closed. Purchase orders must not already be closed or archived. The user must have permission to close every purchase order in the request.
Use only after confirming the user wants the listed POs reopened. This does not archive or delete POs; reopening restores each PO to its computed active lifecycle status when allowed. The user must have permission to reopen every purchase order in the request.
Marking an object (for example a transaction) as ready to sync flags it as reviewed and complete, so it will be included in the next accounting sync that exports data from Ramp to your connected accounting provider (ERP), such as NetSuite, QuickBooks, Xero, or Sage Intacct.
Releases the active vendor-scoped hold and allows new payments to be scheduled for the vendor. Payments that were removed from scheduled payment flows while the hold was active must be scheduled again after the hold is released.
Use this tool when the user wants to nudge approvers for specific bill UUIDs. The bills should be awaiting approval; use get-bills-for-approval first if the user has not identified the bill UUIDs.
Remove a saved loyalty program from the user's traveler profile
Remove a user from a shared fund using user_email
Department names must be unique within the business (case-insensitive).
Use this after selecting a dataset name to inspect its dimensions, measures, default time dimensions, sample questions, and join-reachable fields before constructing a ReportQuery.
Call once before your first reporting query and follow it exactly.
Call `ramp_reporting_get_skill` before your first reporting query and follow the returned skill. Use this before building a semantic reporting query when you need to know which datasets exist and how each dataset is described at a high level.
Search tags are used to filter report data by various criteria such as: - Users (employees) - Vendors/Merchants - Departments - Locations - Tracking category options (custom accounting dimensions) Use this tool when you need to find specific entities to use as filters in a report. This is typically used before creating or modifying a report to find the correct search tag IDs.
Data is eventually consistent (may lag a few minutes). Execute a semantic reporting query and return typed rows. Requires a dataset and fields from the semantic catalog. The `report_query` input is a ReportQuery: dataset, dimensions, measures, filters, post-aggregation having or aggregate-filter clauses, optional time range, per-dimension ranking, ordering, and limit. A `filters` clause whose `field` is a catalog field is a row predicate; one whose `field` is a selected measure output name (its `name` alias when present) is the preferred aggregate predicate and applies after grouping (HAVING), e.g. `{"field": "txn_count", "op": "gt", "value": 3}`. `having` and `aggregate_filters` remain supported equivalents, but are deprecated and migrated into `filters`; `result_metadata.predicate_migration` records the migration. Order by any selected orderable dimension or measure output. A measure ref may carry its own `filters` plus a unique `name` to emit a conditional aggregate column ("sumIf"). Select the same measure several times with different filters for side-by-side cohort columns, e.g. one spend total per category grouped by user, including an "other" column via a NOT_IN filter. Measure filters use the same field/op/value shape as query filters but only base-dataset fields. Use `post_aggregation` to count the first-stage groups that survive the aggregate predicates (a measure-output `filters` clause or the deprecated forms, which migrate like any other query). For example, select attendee plus `{"field": "spend_date", "time_grain": "day"}`, filter daily_spend over $100, then use `{"dimension": "attendee", "name": "days_over_limit"}`. Use attendee rather than user so group meals stay allocated correctly, and keep the daily grain so the count is by UTC calendar day. Use `max_groups` for K named values plus Other independently on every selected non-time dimension, retaining all time buckets. Set `ranking_order_by` to selected first-stage measure scores. When the time range is omitted, ranking covers all authorized data. Display `order_by` is separate. Omit `limit`; ranked results have a 1,000-row cap disclosed through result_metadata.is_truncated. Ranking cannot combine with aggregate predicates or post_aggregation.
Use this when a user describes a reporting question in plain English and you need to choose the best semantic dataset and relevant fields.
This is the REVIEWER / APPROVER action: the acting user must be an approver or manager for the transaction, not the cardholder themselves. The tool marks the transaction as repayment-required and notifies the cardholder, who can then accept, reject, or complete repayment through their own flow. This tool does NOT execute payment (ACH, payroll, debit-card, etc.). It only creates the repayment request so the cardholder sees an actionable task. Use when a reviewer or manager says things like: - "Request repayment on this transaction" - "Mark this as needing repayment" - "Require the employee to pay back this charge" - "Flag this transaction for repayment" If the user is the cardholder wanting to repay their OWN transaction, use RepayTransaction instead — that tool provides the self-service repayment URL.
This does NOT submit the reimbursement — it only moves it from REJECTED to DRAFT. After resubmitting, use EditReimbursement to make changes and SubmitReimbursement to submit again.
Only valid after a publish approval was rejected. The rejected approval workflow is terminated and the RFX becomes editable again.
This is irreversible — on a published RFX the vendor immediately loses access to the questionnaire and any e-sign envelope in flight is voided. DRAFT invitations are deleted outright; ACTIVE invitations are revoked (keeping their contact on record). Already-revoked invitations fail cleanly. Use GetRFXDetail to review invitations before revoking.
List custom roles
Accepts a UUID in query even when the bill's draft/submitted stage is unknown. Each result includes lifecycle information: is_draft=true means an unsubmitted draft; is_draft=false means a submitted bill. Also supports text search by payee name, invoice number, or payment ID. Submitted and active draft bills may both be returned unless filters exclude them; include_drafts=False restricts results to submitted bills. An unpaid bill or one awaiting approval is not necessarily a draft.
First inspect the booking itinerary and ask which leg, date, or route the traveler wants to change. Pass one entry per changed leg, identified by its 0-based ``leg_index``. Unspecified date and airport fields retain the original leg values. When changing both legs of a single-ticket round trip, first search with both leg modifications, present the outbound offers, then call again with the chosen ``selected_outbound_offer_id`` and the same modifications to retrieve matching returns. Split-ticket bookings must instead be changed one leg at a time; never combine their legs or use ``selected_outbound_offer_id``. Some bookings support the first search but not this second step, and return an unsupported-provider result with support details; route the traveler to that support rather than retrying. Search prices are estimates; call SubmitFlightModification to re-quote the selected offer with the airline before asking the traveler to confirm. ``recommended_offers`` is always present, ranked from this page of ``offers``; each surface presents those entries in the format it supports, and ``assistant_note`` states which presentation applies.
Before first use in a conversation, load and follow the ramp-book-flight skill when available. Tell the tool what to search (route + dates), or give it a job_id - never both. Start a NEW interactive search with wait_for_results=false: it returns a job_id immediately, so ask the traveler's unresolved preferences while the search runs and resume with the same job_id on a later call. Blocking (wait_for_results=true, the default when omitted) is the exception for flows that need a complete result immediately and cannot resume later. A call with job_id reads cached results and never starts another provider search. Use job_id alone with wait_for_results=true to read the completed first page, add cursor to read the next page, add preferences to change the filtered or ranked view, or add sort_key to change its order; omit cursor when making either change so the new view starts at its first page. For a round trip, start the search with return_date. The first response contains OUTBOUND offers with is_round_trip=true and round-trip totals. Choose an outbound offer, then call with its job_id and outbound_offer_id to get matching RETURN offers. The chosen return offer's id identifies the complete outbound-and-return itinerary for booking. To filter return offers (e.g. by airline), pass the same job_id and outbound_offer_id with the new preference - do not start a new search, which discards the selected outbound flight and reruns the entire provider query. A completed outbound response includes web_search_url for the cached search in Ramp Travel. Fare options are nested under their flight, and a nested fare option id can be selected for return offers. Search preferences are cabin_class, required_upgrade_cabin_class, airlines, max_stops, only_split_tickets, preferred_departure_time_window, preferred_arrival_time_window, and avoid_red_eye_flights; omitted preferences retain their prior values, and applied_preferences reports what each response used. Do NOT use this tool to change, modify, cancel, or rebook an existing booking.
This tool performs semantic search across help center articles using embeddings. Trusted business-scoped calls receive the complete matched articles; unscoped and external Developer API calls receive focused snippets. The tool: 1. Fetches relevant articles from the help center 2. Chunks articles into smaller semantic units 3. Uses embedding similarity to find the most relevant sections 4. Returns top K results with their source articles Some internal articles have no public URL (an empty ``url``). Never construct or guess a URL for those articles. IMPORTANT: If you have other tools that can actually perform the action a user is asking about, you should use those tools instead of or in addition to providing help center information. For example, if a user says "how can I upload a receipt", you should tell them they can upload a receipt in the chat directly, even if you also find a help center article that explains how to upload receipts in the web app. Use this tool when you need to: - Find specific information within help articles - Get concise, focused answers from documentation - Minimize token usage while maintaining relevance - Answer questions about Ramp products and features
Before first use in a conversation, load and follow the ramp-book-hotel skill when available. Provide location_query (city, neighborhood, address, landmark, or office) plus check_in_date and check_out_date. API calls run synchronously by default and return ranked hotels - each with at most one summary rate - plus policy_summary, total_count, and web_search_url. Results are paginated from a cached result set: pass the returned next_cursor as cursor to fetch more hotels without triggering a new provider search; never construct or edit a cursor. Put chain requests in filters.chain_names and reserve hotel_name for one exact property; a specific hotel_name uses the targeted direct-hotel path. Passing wait_for_results=false explicitly opts into an asynchronous kickoff that returns status='searching' with a search_id to resume by passing that search_id on a later call. To book from these results, pass the selected hotel id to GetHotelRates, then the selected rate id to SubmitHotelBooking with the same traveler and stay dates.
Returns matching merchant IDs, UUIDs, names, categories, and domains.
Search for purchase orders using structured purchase order filters
Search reimbursements across a business, optionally filtering to a specific user's reimbursements
Use this to find existing purchase orders, fund requests, procurement requests, policy-backed requests, or approval-only requests by vendor, request name, spend program, owner UUID, requester UUID, status, type, exact request number, approval date, department, workflow-backed policy, or whether they require action. Only requests the acting user owns, requested, can approve, or is otherwise permitted to view are searchable. Use GetRequestsToReview when the user is specifically asking what they need to approve right now. Use GetUnifiedRequestDetails once one request has been identified. For a draft policy-backed request, pass the result's exact wbp_request_id to ResumeWbxRequest, not its unified_request_id.
Returns users from the business ranked by relevance to the given transaction (recent attendees and teammates appear first). If no transaction ID is provided, the user's most recent transaction is used as context. The search is case-insensitive and matches partial names.
Supports filtering by: - User name (e.g., 'John Smith') — resolved automatically, defaults to current user if not specified - Accounting coding selections (tracking categories) like Department, Cost Center, Class, GL Account - Merchant name, spend allocation name (resolved from text automatically) - Reimbursement status (DRAFT, PENDING, APPROVED, etc.) - Record creation date range and text search The tool resolves text queries to internal IDs automatically via the search tag service. Results are scoped to the current user's business. Date bounds filter when the reimbursement record was created, not when the expense occurred or was submitted. This tool does not support filtering by transaction date or submission date, or ranking employees by period totals.
With a search_term, this tool finds vendor records using both fuzzy SQL matching (trigram similarity + substring) and semantic (vector) search. Without a search_term, it lists the business's vendors alphabetically. Use this to find vendor IDs when you need to: - Look up a vendor by partial name - Find the correct vendor UUID for further analysis - Discover vendors similar to a given name - List vendors, optionally filtered by 1099 tracking status The search is scoped to the current business context.
submitted their RFX response. Only ACTIVE invitations on a published RFX whose vendor has not rejected the invitation and has not submitted are eligible. A per-vendor cooldown prevents spamming — recently reminded vendors are skipped and reported in ``skipped_due_to_cooldown_invitation_ids``. Omit ``rfx_vendor_invitation_ids`` to remind every eligible vendor.
Decline buffers are stored as allowed overage percent. Use this purpose-built tool for decline/spend/overage buffer changes instead of generic endpoint tools. Always confirm the exact target and value with the user before calling this tool. Clear is distinct from 0%. Passing allowed_overage_percent=null removes the explicit value at the target level so it can inherit from the next level. Passing allowed_overage_percent=0 sets an explicit zero-percent buffer. Spend-program changes always propagate to existing linked allocations. For business-wide settings, buffer_application_mode is required when setting a non-null percent.
Pass body_markdown and/or attachment_ramp_document_ids, and get explicit user confirmation for the body and every attachment before calling.
The pricing sheet configures how vendors submit pricing in response to the RFX: the currency they must quote in, a rich-text guidance memo explaining pricing expectations (e.g. unit basis, term length, must include implementation), and optional background attachments (rate cards, SOW templates) for vendors to reference. The guidance memo and attachments are vendor-facing (sent on publish). The agent MUST get explicit user confirmation on the guidance wording and on every attachment before calling this tool. Never auto-attach files the user uploaded earlier in the thread — those may be internal/confidential and attaching them to a vendor-facing surface is a data-leak risk. Creating a pricing sheet implicitly enables vendor pricing on the RFX — once this tool succeeds, vendors will see a pricing step in their response flow. The very first call (when no pricing sheet exists yet) must include both `currency` and `guidance_markdown`. After that, partial updates are allowed. Patch semantics: - Pass `currency` to replace the currency. Omit (None) to leave unchanged. - Pass `guidance_markdown` to replace the guidance memo. Omit to leave unchanged. - Pass `attachment_ramp_document_ids=[id1, id2]` to replace the attachment set. Pass `[]` to clear all attachments. Omit (None) to leave unchanged. Requires the RFX to be in DRAFT state. The acting user must be an owner or collaborator on the RFX.
Resolving a DRAFT invitation's contact activates it (DRAFT → ACTIVE) so the RFX can publish; DRAFT invitations without a contact block publishing. On an ACTIVE invitation this swaps the contact who receives vendor-facing communication. Use GetRFXDetail to find invitation ids and current contacts, and the vendor contacts surface to find payee_contact_id values for the invited vendor.
If it already exists, update its loyalty number. After success, continue the active workflow when it requires refreshed data; otherwise tell the user it is saved.
Approval policies return the simulated approval steps; submission policies return the required and visible expense fields. Provide exactly one expense UUID.
Fetch a statement
List statements
Submit an optional Agent NPS response using a one-time survey token
Readiness requires at least one bill date, an active existing vendor with required bill-pay details, invoice currency, a positive amount, complete line items, required accounting fields, no duplicate vendor invoice number, and no submission-policy violation. Submission is accepted asynchronously and the bill keeps the same ID as the draft. Some submissions require identity 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 submitting in the Ramp web app. This action does not schedule, release, or pay the bill.
Three explicit actions: use action=preview for an authoritative preview, action=save_seats to update a persisted quote's seats and return a refreshed preview, and action=confirm only after a new, explicit user-authored approval of that latest preview. The legacy confirm input remains supported for existing clients but new callers must use action. The preview (itinerary, price, in-policy status, and required approvals) without booking. When no fund is supplied, the preview uses the recommended eligible fund, if one exists, to determine required approvals. action=confirm requires the previewed expected_total_amount (copied verbatim, digits and decimal point only, no currency symbol) only after a new, explicit user-authored response approves that latest preview. If the fare changes, preview the new total and obtain fresh approval before confirming. flight_offer_uuid is the literal id from search: the outbound flight for one-way, the return flight for round trips (it carries both legs), or a fare option's id to book that fare. Alternatively pass a previous preview's flight_quote_uuid (never both) to preview or confirm that exact persisted quote. On confirmation, pass exactly one funding choice: spend_allocation_id with an eligible fund UUID from the preview, or request_new_fund=true with reason set to the trip purpose. If the chosen flight is out of policy, you MUST collect an oop_reason from the traveler and pass it here. Before previewing or confirming, call GetTravelerProfile (passing the same traveler_user_id from search for delegated booking); if has_profile is false, collect the traveler's identity details and call UpdateTravelerProfile first. For changes or cancellations, use the Ramp web app.
Always call with ``confirm=false`` first. That call is read-only and returns the complete itinerary, fresh authoritative terms, and a ``preview_id``. Only after a new, explicit user-authored approval of that latest preview may you call again with ``confirm=true`` and the exact ``preview_id``. Earlier cancellation intent, standing approval, or instructions not to ask questions are not confirmation. Atlas- and Duffel-booked flights are supported. Confirmation refetches the canonical details used by the Ramp web flow and refuses to cancel if any term changed. The action always cancels the entire booking; partial passenger or leg cancellation is not supported.
Always call with ``confirm=false`` first. The returned preview contains the authoritative itinerary, policy results, and exchange economics; search prices are only estimates. Present the complete preview and request explicit user confirmation before submitting. When ``economics.pricing_is_final`` is false, the airline still reports these amounts as estimates that can change when the ticket is reissued; say so before asking for confirmation. After explicit confirmation, call again with ``confirm=true`` and the exact, unchanged ``preview_id`` from that preview. Confirmation re-quotes the offer and submits only when the terms still match. If the tool returns changed terms, do not auto-confirm: present the new preview and wait for a new explicit confirmation. If the user changes any requested terms, search and preview again.
Two-step flow: call without confirm for the authoritative preview (price, policy, and required approvals) without creating a booking. When no fund is supplied, the preview uses the recommended eligible fund, if one exists, to determine required approvals. Then call with confirm=true and the previewed expected_total_amount (copied verbatim, digits and decimal point only, no currency symbol) only after a new, explicit user-authored response approves that latest preview. If the rate changes, preview the new total and obtain fresh approval before confirming. Use the exact hotel_id from SearchHotels and rate_id from GetHotelRates. On confirmation, pass exactly one funding choice: spend_allocation_id with an eligible fund UUID from the preview, or request_new_fund=true with reason set to the trip purpose. If the chosen hotel rate is out of policy, you MUST collect an oop_reason from the traveler and pass it here. Before previewing or confirming, call GetTravelerProfile (passing the same traveler_user_id for delegated booking); if has_profile is false, collect the traveler's identity details and call UpdateTravelerProfile first. If the user wants to change or cancel an existing reservation, direct them to the Ramp web app.
Always call with ``confirm=false`` first. That call is read-only and returns fresh authoritative terms plus a ``preview_id``. Only after a new, explicit user-authored approval of that latest preview may you call again with ``confirm=true`` and the exact ``preview_id``. Earlier cancellation intent, standing approval, or instructions not to ask questions are not confirmation. Confirmation refetches the canonical details and refuses to cancel if any material hotel cancellation term changed. This tool always cancels the entire hotel booking; use the flight cancellation tool for flights.
If the submission fails, the agent should follow up with the user based on the error returned from the endpoint. If it is due to outstanding missing items, the agent should recheck missing_items via the GetReimbursements tool and provide suggestions for the user. If only nonsupported missing items are present (trip, attendee, mileage_locations), the agent should provide the reimbursement_link URL as a clickable link in the response.
User profile fields reflect current Ramp user metadata, independent of the requested dates. Only users with positive estimated spend are returned.
Send line_items with amounts (in minor units) to create or replace the transaction's split; the line item amounts must sum to the transaction amount. Each line item can carry its own memo and accounting field selections. Send an empty line_items array to unsplit (remove all line items). Returns the updated transaction.
Transfer ownership of a spend allocation using the current and new owners' emails
Only act when the user's current instruction explicitly identifies this request or unambiguously refers to this exact request from the immediately preceding assistant preview. Never infer another pending or remaining request after completing an action.
Unarchive a fund so it becomes visible and spendable again
Requires the user to confirm they recognize the flagged transaction.
Manages spend types (e.g., Restaurants, Travel), not individual merchants.
Requires the current draft version and returns the new version; stale updates are rejected with the current version. Omitted fields remain unchanged, while null intentionally clears a nullable field. Tracking-category and option identifiers accept integer DB ids or resolvable UUID strings. Submitted drafts and drafts with retainage (withholding) are not supported.
- Add or remove merchants from the allowed merchants list (whitelist) - Add or remove merchants from the blocked merchants list (blacklist) Use this when a user wants to: - Allow specific merchants on a fund (add to whitelist) - Block specific merchants on a fund (add to blacklist) - Remove merchants from the allowed or blocked lists
``sections`` is a complete replacement of the questionnaire — resubmit the full section list on every update. Use GetRFXDetail first to see the current structure. Optional scalar fields left unset are unchanged.
Update only the spend interval for a spend allocation
Use this for decline action INCREASE_TRANSACTION_AMOUNT_LIMIT or requests about a per-transaction, single-transaction, or max-expense limit. Use LimitIncrease for the period total. Set any positive value to raise or lower the cap. AP-card and bill-pay funds are unsupported. Provide exactly one of spend_allocation_id or card_id.
Purpose: Capture HIGH-SIGNAL, reusable preferences that improve future flight and hotel recommendations. Call this tool proactively ONLY when the user states a lasting, general preference — signaled by words like "always", "never", "I prefer", "from now on", "in general", or "usually". ALL THREE conditions must be met before calling: 1. Durable — likely true across trips, not just this one 2. Actionable — directly improves hotel or flight recommendations 3. Explicit — clearly stated by the user, not inferred Good examples (call the tool): - "I always stay at Marriott" → hotel chain preference - "I need a gym when I travel" → amenity requirement - "I prefer downtown hotels" → location style - "Nothing below 4 stars" → quality floor - "I prefer morning flights" → flight time preference - "I always fly out of SFO" → preferred airport - "Never book red-eyes" → avoid_red_eye_flights=True Do NOT call for (vast majority of travel messages): - Trip-specific requests ("this time find something cheap") - Trip-specific timing constraints ("arrive before 3pm this trip") - Search parameters ("find me a hotel near Times Square for March 20") - Policy or fund choices ("use the offsite fund", "make it in policy") - Questions ("what hotels are available?") - Booking actions ("book option 2") - Speculation or inferences not stated by the user - Sensitive PII (passport numbers, payment details, full DOB) For explicit durable flight preferences, pass the typed fields below. Leave fields omitted to preserve existing saved values. Use null only to clear nullable durable defaults. Use [] to clear list-valued preferences. When in doubt, do NOT call. Most messages should NOT trigger this tool.
Compatibility route for callers that still update a saved loyalty program by ID
Never use for loyalty-only requests; use dedicated traveler loyalty program tools instead. For delegated bookings, first resolve the traveler with GetAllReducedUsers/list-users, then pass that UUID as traveler_user_id. Omit traveler_user_id for self-booking.
List daily AI usage and spend grouped by provider, model, and product
Before calling, use ListBusinessAccounts to obtain the destination account UUID; never guess it. Confirm the exact destination account and USDC 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.
The Ramp MCP integration connects your Dench AI CRM directly to Ramp MCP, so agents can read and act on your Ramp MCP data as part of everyday work — answering questions in chat, keeping your CRM in sync, and running automations without anyone copying data between tools.
213 actions are available for agents to invoke on your behalf. Every call runs through Ramp MCP's own authorization, scoped to the account you connect.
Sign in to your Dench workspace and open Integrations.
Find Ramp MCP and click Connect — you'll authorize access through Ramp MCP's own sign-in flow. No API keys or code required.
Ask an agent to use Ramp MCP in chat, or call it from an automation.
Manage or disconnect the connection any time from workspace settings.
The Dench Ramp MCP integration connects your AI CRM to Ramp MCP, so AI agents can work with your Ramp MCP data as part of chats, automations, and CRM workflows. You connect your account once, and every agent in your workspace can use it — governed by your workspace permissions.
The Ramp MCP integration currently exposes 213 actions, including Ramp activate card, Ramp add traveler loyalty program, Ramp add user to shared fund, Ramp agent account numbers, Ramp answer policy question, and Ramp api keys. Agents invoke them on your behalf from chat or from automations.
No. You connect Ramp MCP from your Dench workspace using Ramp MCP's own sign-in and authorization flow — no API keys to copy, no glue code to maintain.
Connections are authorized through Ramp MCP's own authentication flow, and Dench stores only the authorization needed to act on your behalf. You can review and disconnect the Ramp MCP connection from your workspace settings at any time.