How to Connect AI Agents to Brex: Automate Expense Management via MCP

To give an AI agent read and write access to Brex - pulling transactions, issuing virtual cards, adjusting budgets - you need more than a simple REST API wrapper. You must deploy a Model Context Protocol (MCP) server that translates the agent's natural language intent into standardized JSON-RPC tool calls, while managing OAuth tokens, rate limits, and Brex's specific schema quirks. This architecture handles strict API limits and normalizes complex nested financial schemas without forcing your engineering team to build custom connectors for every LLM your customers use.

The timing matters. Capital One completed its $5.15 billion acquisition of Brex in April 2026, and the company already leverages AI agents to help customers automate complex workflows to reduce manual review and control spend. The convergence of corporate spend management and AI is not speculative - it is happening at the infrastructure level right now.

If you are a product manager or engineering leader tasked with giving an LLM read and write access to corporate financial data, you already know that brute-forcing point-to-point API integrations is an unscalable approach. This guide covers the architecture, the real pain points, and what it takes to make a Brex MCP server work securely and at scale in production.

The Rise of AI-Driven Expense Management

The demand for intelligent financial automation is accelerating. The AI-driven expense report automation market was valued at $3.22 billion in 2026, growing from $2.82 billion in 2025 at a compound annual growth rate of 14.2%. The broader expense management software market hit an estimated $9.29 billion in 2026. Gartner further predicts that by 2025, 80% of organizations will rely on expense analytics tools to drive tangible business value from their financial data.

These numbers reflect a structural shift, not a hype cycle. Best-in-class platforms automatically process up to 85% of expenses without human intervention, yet companies relying on manual workflows still spend anywhere from $12 to $26 per invoice, compared to $2 to $4 with full automation. The gap is enormous, and AI agents are the most direct path to closing it.

We are moving past simple OCR receipt scanning. Modern AI agents are expected to independently verify corporate card transactions against dynamic budgets, adjust spend limits based on natural language requests from department heads, and automatically reconcile anomalies before month-end close.

Building these capabilities requires deep, reliable access to the Brex API. But as we've seen when connecting AI agents to Plaid, exposing a financial API to a non-deterministic language model introduces severe architectural challenges. LLMs do not inherently understand OAuth token lifecycles, they hallucinate pagination cursors, and they fail spectacularly when confronted with undocumented rate limits. For engineering teams building financial products, the question has moved from "should we automate expense workflows?" to "how do we connect our agent to the financial system without building and maintaining bespoke API connectors?" That is where the Model Context Protocol enters the picture.

Why Point-to-Point Brex API Integrations Fail for AI Agents

Brex APIs use the REST architecture, are defined using the OpenAPI specification, and use standard HTTP response codes and verbs. All APIs accept and return JSON and require HTTPS. On paper, this sounds straightforward. Historically, exposing a SaaS product to an AI model meant writing custom LangChain tools or OpenAI function-calling wrappers for every single endpoint.

In practice, for a system as complex as Brex, this approach collapses under its own weight, turning a direct connector into a multi-month project with ongoing maintenance costs. Here is what you are actually signing up for:

The Token Expiration Trap

Authentication is the first failure point. Brex supports two authentication modes. The user token is used to authenticate your own Brex account. The OAuth token is used when building partner applications to authenticate other Brex accounts. User tokens expire if they are not used to make an API call for 30 days. When used regularly, they will not expire. The OAuth token lasts for one hour and then must be refreshed.

This means if your AI agent goes quiet for a month - maybe it is only triggered during quarterly audits or seasonal reviews - the user token silently dies. The agent fails, the workflow breaks, your customer files a ticket, and you spend a morning debugging a 401 error that has nothing to do with your code. The end-user is forced to manually re-authenticate.

For partner integrations using OAuth, you are on the hook for refreshing tokens every hour, handling refresh failures gracefully, and dealing with the revocation edge cases that every OAuth implementation eventually hits. Managing these lifecycles across thousands of distributed AI agents requires dedicated background scheduling infrastructure, not just a simple database table.

Rate Limits That Bite During Bulk Operations

The Brex API employs rate limits as a safeguard against abuse and to ensure API stability. Per Client ID and Brex account, they allow up to 1,000 requests in 60 seconds, up to 1,000 transfers in 24 hours, up to 100 international wires in 24 hours, and up to 5,000 cards created in 24 hours.

1,000 requests per minute sounds generous until an LLM decides to paginate through every transaction for a reconciliation task. Each GET /v2/transactions/card/primary call returns a page of results, and a busy Brex account can easily have tens of thousands of transactions in a quarter. Your agent blows through the rate limit, gets a 429 Too Many Requests error, and - if you haven't built explicit retry logic that bubbles up to the agent - the entire workflow fails.

Brex recommends throttling traffic more broadly per Client ID rather than for individual requests. A token bucket algorithm implemented per Client ID may help mitigate or avoid the effect of rate limits. Building that throttling layer is not hard, but it is yet another piece of infrastructure you have to maintain for a single integration.

Pagination and Cursor Hallucinations

Brex relies heavily on cursor-based pagination for listing expenses, accounts, and transactions. LLMs are notoriously bad at handling opaque cursor strings. If you pass a raw Brex API spec to an LLM and ask it to fetch the next page of expenses, the model will often attempt to guess or synthesize the next_cursor value based on the previous response, resulting in malformed API requests and broken pagination loops.

The API Surface Area and N x M Integration Problem

Brex exposes multiple API domains: Accounting API, Budgets API, Expenses API, Fields API, Onboarding API, Payments API, Team API, Transactions API, Travel API, and Webhooks API. Each has its own endpoint structure, pagination model, and schema. The Team API alone lets you manage users, departments, locations, and cards. Translating all of this into a set of tools that an LLM can reason about requires writing schemas, descriptions, and parameter mappings for every endpoint you want to expose.

If you build a custom Brex tool for Claude, you must rewrite it for OpenAI. When your customers demand support for Gemini, a LangChain agent, or local models via Cursor, you have to rewrite it again. This N x M integration matrix drains engineering resources and leaves you maintaining dozens of brittle API wrappers instead of improving your core product.

What is a Brex MCP Server?

The Model Context Protocol (MCP) is an open standard that defines how AI models connect to external tools and data sources. Anthropic launched MCP in late 2024, and it has rapidly become the universal adapter for AI connectivity.

A Brex MCP server is a JSON-RPC 2.0 endpoint that exposes Brex API operations as standardized, callable tools for any MCP-compatible AI client. Instead of teaching the LLM how to format HTTP requests, handle OAuth headers, and parse Brex's specific JSON schemas, the MCP server abstracts these mechanics entirely. You build (or use) one MCP server, and every client that speaks the protocol gets access to the same set of Brex tools.

Several approaches exist in the market:

• Composio: Positions itself as a tool router for AI agents, offering a Brex MCP server that supports direct API and MCP-based integrations.
• UBOS.tech: Offers a Brex MCP server positioned as a bridge for businesses to streamline expense management.
• Open Source (e.g., crazyrabbitLTC): Custom MCP servers optimized for safe, read-only responses with batching to handle Brex API pagination.

While open-source wrappers are excellent for prototyping, enterprise deployments require managed infrastructure that guarantees zero data retention, automated token refreshes, and standardized rate limit handling.

The MCP standard defines a simple handshake: the client sends tools/list to discover what the server can do, then sends tools/call to invoke a specific operation. The server handles authentication, schema validation, and the actual API call to Brex.

sequenceDiagram
    participant Agent as AI Agent (Claude/GPT)
    participant Client as MCP Client
    participant Server as Brex MCP Server
    participant Brex as Brex API

    Agent->>Client: Natural language intent<br>"Fetch recent marketing expenses"
    Client->>Server: tools/list
    Server-->>Client: [list_brex_expenses, get_brex_budget...]
    Client->>Server: tools/call<br>method: list_brex_expenses
    Server->>Brex: HTTP GET /v1/expenses<br>Authorization: Bearer {token}
    Brex-->>Server: JSON Response + next_cursor
    Server-->>Client: Standardized Tool Result
    Client-->>Agent: Structured Context

The key architectural benefit is decoupling. The agent does not need to know Brex's pagination model, its OAuth refresh cycle, or how to interpret a 429 response. The MCP server handles all of that. The agent just sees a tool called list_brex_expenses with a JSON Schema describing what parameters it can pass.

Key Use Cases: Automating Brex Workflows via MCP

When you expose Brex through a well-architected MCP server, you unlock sophisticated agentic workflows that go far beyond simple data syncing. The use cases become a function of the agent's reasoning, not your connector's capabilities.

1. Automated Receipt Matching and Expense Coding

An AI agent monitoring a shared finance inbox, Slack channel, or mobile app can ingest a PDF receipt, use a vision model to extract the vendor, date, and total amount, and immediately query the Brex MCP server using the list_expenses or Transactions API tool. The agent cross-references the extracted data against open card transactions. If a match is found, the agent uses the update_expense tool to attach the receipt ID and apply the correct GL code based on historical patterns. This eliminates the manual task that accounts for most of the $12-$26 per-invoice cost in non-automated workflows - entirely without human intervention.

2. Dynamic Spend Limit Adjustments

The Brex API exposes endpoints to get the monthly limit for a user including the monthly available limit, and to set the monthly limit for a user. The limit amount must be non-negative, and setting monthly_limit to null unsets the limit.

Consider an engineering manager who asks an internal AI assistant, "Can you increase the AWS budget on my virtual card by $500 for this week?"

The agent uses the MCP server to call the Brex get_card tool, verifies the user's current limits, checks internal approval routing rules (perhaps monitoring project milestones or headcount changes), and then executes an update_card_limit tool call. A new contractor onboards? The agent creates a virtual card with a specific spend limit. A project wraps? The agent locks the card. The natural language request is securely translated into a verified API mutation with no manual dashboard clicks required.

3. Natural Language Budget Querying (RAG)

Finance leaders need real-time answers without logging into BI dashboards. An executive or CFO can ask a Slack bot, "How much of our Q3 travel budget is remaining?" or "How much did the marketing team spend on SaaS tools this month?" The agent queries the Brex list_budgets or list_brex_transactions endpoint, filters for the appropriate category, aggregates the results by merchant, calculates the remaining balance, and returns a concise, accurate summary.

4. Programmatic Card Issuance for Vendor Payments

Brex allows creating new cards via API. The spend_controls field is required when limit_type is CARD. Each user can only have up to 10 active physical cards. An agent can issue single-use virtual cards for vendor payments, each with a specific limit and expiration, then automatically terminate them after the payment clears.

Handling Brex API Rate Limits and Authentication in Production

This is where most DIY integrations fall apart. Enterprise APIs protect their infrastructure aggressively. Let's be specific about what production readiness requires.

Authentication: OAuth Token Refresh Before Expiry

As mentioned, Brex user tokens expire after 30 days of inactivity, and partner OAuth tokens last one hour. If your MCP server does not proactively refresh tokens before they expire, the agent will hit 401 errors mid-workflow.

A managed platform handles this complex token refresh logic in the background. The platform schedules token validation checks and automatically negotiates new access tokens shortly before the expiration window closes, preventing interruptions during active agent sessions. For user token-based connections, the platform makes periodic keep-alive calls to prevent the 30-day inactivity expiration from triggering silently. The AI agent never loses access, and the end-user is never bothered with re-authentication prompts.

Rate Limits: Pass-Through, Not Absorption

A common architectural mistake is building a middleware layer that attempts to absorb rate limits by silently catching an HTTP 429 (Too Many Requests) and automatically retrying with exponential backoff. This blocks the AI agent's execution thread. The agent sits idle, waiting for a response, wasting expensive compute cycles, which creates unpredictable latency and can mask systemic issues.

Radical honesty is required here: middleware should not hide rate limits from AI agents.

A production-grade architecture takes a pass-through approach. It does not retry, throttle, or apply backoff on rate limit errors. When the Brex API returns an HTTP 429, that error is passed directly back to the caller. The upstream rate limit information is then normalized into standardized headers per the IETF specification:

HTTP/1.1 429 Too Many Requests
ratelimit-limit: 1000
ratelimit-remaining: 0
ratelimit-reset: 1715094800

This deliberate design forces the AI agent (or the orchestration framework like LangGraph) to handle the backoff natively. The agent receives the error, reads the ratelimit-reset timestamp, and can intelligently decide to yield execution, pause, batch remaining calls, or work on a different task until the limit resets. Silently absorbing 429s would rob the agent of that critical signal.

Scoping Access with Tool Tags and Permissions

Security is paramount when connecting AI to financial systems. You rarely want a single agent to have unrestricted access to every Brex endpoint. Brex tokens use permission scopes that control what level of data access the token has. An agent that only needs to read transactions should not have write access to payments.

When creating an MCP server scoped to Brex, you can restrict it to read-only operations (get, list) so the agent physically cannot issue cards or initiate transfers even if the underlying token has broader permissions. Furthermore, you can utilize tool_tags to group and filter capabilities. A Brex integration might tag the expenses and receipts endpoints with ["expense_management"], while tagging users and departments with ["directory"]. When you provision the MCP server URL for a specific agent, you can restrict it to only serve tools matching the "expense_management" tag. The agent literally cannot see or call the directory endpoints, drastically reducing the blast radius of a compromised or hallucinating model.

How Truto Auto-Generates Brex MCP Tools

Writing and maintaining custom tool definitions, JSON Schemas, parameter mappings, and descriptions for every endpoint across Brex's nine API domains is a massive operational burden. It means weeks of work and permanent maintenance overhead. Truto eliminates this by dynamically generating MCP tools from Brex's API documentation and resource definitions.

The process works like this:

1. Resource Discovery and the Documentation-Driven Quality Gate

Brex's API endpoints are defined as resources in a declarative configuration - transactions, cards, budgets, users, expenses, and so on. Each resource specifies the methods it supports (list, get, create, update, delete).

Truto derives tool definitions from two data sources: this resource configuration and the documentation records (which provide human-readable descriptions, query parameter schemas, and request body schemas). These are authored as structured YAML and compiled into JSON Schema at runtime.

Crucially, a tool only appears in the MCP server if it has a corresponding documentation entry. This acts as a strict quality gate. You do not want an AI agent hallucinating parameters for an undocumented endpoint. If a Brex method lacks documentation, the tool is entirely skipped during generation, preventing exposure of unstable endpoints to the agent.

2. Enhancing Schemas for LLM Comprehension

Raw API schemas are often too ambiguous for LLMs. Truto automatically enhances the auto-generated MCP tools to guide the model's behavior.

For example, when generating a tool for a Brex list method, Truto automatically injects limit and next_cursor properties into the JSON Schema. The description for next_cursor is heavily engineered to prevent hallucinations:

{
  "type": "string",
  "description": "The cursor to fetch the next set of records. Always send back exactly the cursor value you received (nextCursor) without decoding, modifying, or parsing it. This can be found in the response of the previous tool invocation as nextCursor."
}

This explicit instruction forces the LLM to treat the cursor as an immutable string, eliminating the pagination errors that plague custom integrations.

3. Dynamic Tool Assembly and Naming Conventions

On every tools/list request, the server builds the tool list from the current configuration. Tools are not cached or pre-compiled. This means when Brex adds new API endpoints and Truto adds the corresponding resource definition and documentation, the tool appears in the MCP server without any code changes.

The generated tools follow predictable naming conventions:

Each tool includes JSON Schema definitions for its parameters, which the LLM uses to construct valid API calls. Pagination cursors, limit parameters, and required ID fields are injected automatically based on the method type.

Zero Data Retention Architecture

Brex data is financial data. Expense records, transaction amounts, card numbers - none of this should sit in a middleware layer's database. When dealing with corporate financial data, security and compliance teams will heavily scrutinize your architecture. If your integration middleware caches Brex transaction data, stores receipts in a proprietary database, or logs raw API responses for debugging, you are expanding your compliance scope and introducing massive data privacy risks.

Truto operates as a real-time proxy with zero data retention. When the AI agent calls a Brex tool like list_all_brex_transactions, the request passes through Truto, hits the Brex API, and the financial data is returned directly to the agent.

Truto does not cache the response body. We do not store sensitive expense data in our databases. We hold the OAuth token to facilitate the connection, but the actual payload flows through purely in memory. Nothing is logged with PII or stored at rest. For teams operating under SOC 2, GDPR, or handling financial data subject to PCI-DSS, this pass-through design eliminates an entire category of compliance risk, as your middleware provider is not acting as a persistent data store for your customers' financial records.

Architecture: From Agent Query to Brex API Call

flowchart LR
    A[AI Agent] -->|JSON-RPC| B[MCP Server]
    B -->|Token Lookup| C[Auth Layer]
    C -->|OAuth Refresh| D[Token Store]
    B -->|Proxy Request| E[Brex API]
    E -->|Response + Rate<br>Limit Headers| B
    B -->|Normalized Response<br>+ IETF Rate Headers| A

The MCP server sits between the agent and Brex, handling three core responsibilities:

• Authentication: Resolves the correct OAuth or user token for the connected Brex account, refreshes it if needed, and injects it into the upstream request.
• Schema translation: Maps the flat tool arguments from the agent into the correct query parameters and request body structure that Brex expects.
• Header normalization: Converts Brex's rate limit response headers into the IETF-standard format so the agent's orchestration layer can make informed retry decisions.

What it does not do is store data, retry on 429s, or make assumptions about the agent's intent. The proxy is intentionally thin.

Getting Started: Connecting Brex to Claude or ChatGPT

Once a Brex MCP server is created via a managed platform (either via API or dashboard), the setup on the AI client side is minimal.

For Claude: Settings → Connectors → Add custom connector → paste the MCP server URL. Claude discovers the tools automatically.

For ChatGPT: Settings → Apps → Advanced settings → enable Developer mode → add the MCP server URL. ChatGPT lists the available Brex tools.

The MCP server URL contains an embedded authentication token, so no additional API keys need to be configured on the client side. For higher-security environments, you can enable a second authentication layer that requires a dedicated API token in the Authorization header.

What an MCP Approach Won't Solve

Honesty matters here. An MCP server is not a magic wand for every Brex integration scenario.

• Webhooks: If you need real-time notifications when a Brex transaction posts, you still need to set up Brex webhooks separately. MCP is request-response, not event-driven.
• Complex multi-step workflows with rollback: An agent that creates a card, sets a budget, and assigns a user needs to handle partial failures. If the budget creation fails after the card is created, the MCP server won't automatically roll back. Your orchestration layer needs to handle this.
• Bulk historical data migration: Paginating through years of transaction history via an MCP tool is technically possible but slow. For initial data loads, a direct batch integration is more appropriate.

The MCP pattern excels at interactive, ad-hoc, and medium-volume operations - exactly the kind of work AI agents do well.

Strategic Wrap-up: Where Brex + MCP Is Heading

Connecting AI agents to Brex is no longer a theoretical exercise - it is a baseline requirement for modern finance automation platforms. Brex - now part of Capital One - is a modern, AI-native software platform that already leverages AI agents to automate complex workflows. Over 25,000 companies run their finances on Brex, including DoorDash, Anthropic, Robinhood, and Zoom. The API surface will only expand as the platform integrates Capital One's banking infrastructure.

For engineering teams building AI-powered financial products, the calculus is simple: tasking your team with building and maintaining bespoke Brex connectors for each AI model, managing 30-day user token expirations, and writing bespoke pagination logic is a severe misallocation of resources.

By leveraging a managed MCP server architecture, you shift the burden of schema normalization, authentication, and protocol translation to the infrastructure layer. Your AI agents receive clean, standardized JSON-RPC tools with explicit instructions, strict rate limit transparency, and zero data retention guarantees.

The build vs. buy math has never been more clear-cut for financial API integrations. Stop writing custom API wrappers. Ship the agent logic, expose your integrations as dynamic MCP tools, and let the infrastructure handle the plumbing.