---
title: "Create a Step-by-Step Developer Guide: MCP + Brex Integration"
slug: create-a-step-by-step-developer-guide-mcp-brex-integration
date: 2026-05-26
author: Roopendra Talekar
categories: [Guides, "AI & Agents", Engineering]
excerpt: "A definitive architectural guide to building a Brex MCP server. Learn how to handle OAuth lifecycles, rate limits, and dynamic tool generation for AI agents."
tldr: Connecting AI agents to Brex requires an MCP server that manages strict OAuth lifecycles and standardizes rate limits without storing sensitive financial data.
canonical: https://truto.one/blog/create-a-step-by-step-developer-guide-mcp-brex-integration/
---

# Create a Step-by-Step Developer Guide: MCP + Brex Integration


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. 

The timing for this architectural shift is undeniable. The AI-driven expense report automation market is projected to reach $5.44 billion by 2030, growing at a 14% CAGR. Capital One completed its $5.15 billion acquisition of Brex in April 2026, signaling a massive consolidation of corporate spend management and automated financial infrastructure. 

If you are a product manager or engineering leader tasked with giving an LLM access to corporate financial data, you already know that brute-forcing point-to-point API integrations is an unscalable approach. Many engineering teams are actively trying to create a step-by-step developer guide: mcp + brex integration to standardize how their internal systems and customer-facing copilots interact with financial data.

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.

## Understanding the Brex API and MCP Architecture

Brex exposes a modern REST API, but it comes with strict operational constraints. It relies heavily on OAuth 2.0 Bearer tokens for authentication, enforces aggressive rate limits that return `HTTP 429 Too Many Requests`, and uses cursor-based pagination for listing resources like transactions and expenses.

Large Language Models (LLMs) cannot natively handle these operational constraints. An LLM does not know how to execute an OAuth refresh grant, nor does it inherently understand how to back off exponentially when it hits a rate limit. 

The Model Context Protocol (MCP) bridges this gap. It acts as an intermediary layer. Instead of the LLM making raw HTTP requests to Brex, the LLM communicates with an MCP server using JSON-RPC 2.0. The MCP server exposes specific Brex endpoints as highly structured "tools" with strict JSON Schemas, handles the authentication layer, and normalizes the responses.

Here is how the request lifecycle operates in a production environment:

```mermaid
sequenceDiagram
    participant LLM as AI Agent
    participant MCP as MCP Server
    participant Truto as Truto Platform
    participant Brex as Brex API

    LLM->>MCP: tools/call (list_brex_transactions)
    MCP->>Truto: Proxy Request + MCP Token
    Truto->>Truto: Validate Token & Inject OAuth Bearer<br>Check Method Filters
    Truto->>Brex: GET /v2/transactions
    Brex-->>Truto: HTTP 200 (JSON)
    Truto-->>MCP: Normalized JSON-RPC Response
    MCP-->>LLM: Context delivered to Agent
```

To build this architecture yourself, you must solve three distinct engineering problems: token management, dynamic tool generation, and rate limit handling.

## Step 1: Handling Authentication and OAuth Token Management

Brex requires OAuth 2.0 for third-party integrations. In a multi-tenant SaaS environment, managing OAuth tokens is notoriously difficult. You must securely store the access token, monitor its expiration time, and execute a refresh grant using the refresh token before the access token expires.

If your MCP server attempts to call Brex with an expired token, the API will return an `HTTP 401 Unauthorized`. If your system fails to handle this gracefully, the AI agent will hallucinate a response or crash the workflow entirely.

When building a custom MCP server, engineers often hardcode token refresh logic into the request path. This creates massive latency spikes for the end-user whenever a token happens to expire right before their prompt. 

Truto handles the entire OAuth lifecycle natively. Instead of waiting for a request to fail, the platform automatically refreshes Brex tokens shortly before they expire. This ensures that the MCP server always has a valid Bearer token ready to inject into the outgoing request.

> [!NOTE]
> **Zero Data Retention**<br>
> Truto's pass-through architecture ensures zero data retention, meaning sensitive Brex financial data is never stored in Truto's databases. The platform only stores the metadata and routing rules required to proxy the request. For more details on secure token management, read our guide on [/oauth-at-scale-the-architecture-of-reliable-token-refreshes/](https://truto.one/oauth-at-scale-the-architecture-of-reliable-token-refreshes/).

## Step 2: Exposing Brex Endpoints as MCP Tools

An MCP server must expose a `/tools/list` endpoint that returns an array of available operations. For Brex, this means converting endpoints like `GET /v2/transactions` and `POST /v2/virtual_cards` into JSON-RPC tools with explicit `query_schema` and `body_schema` definitions.

Manually writing and maintaining these JSON Schemas is a massive operational burden. Brex frequently updates its API schemas, and if your MCP tool schema drifts from the actual Brex API schema, the LLM will generate invalid requests.

Truto automatically generates MCP tools dynamically from Brex API documentation. The platform parses the OpenAPI specifications and documentation records, creating tools on the fly. 

Tool names are generated as descriptive snake_case strings. For example, the Brex transaction endpoint becomes `list_all_brex_transactions`. The platform automatically injects specific instructions into the schema to guide the LLM. 

Here is an example of how Truto dynamically structures the query schema for a Brex list tool:

```json
{
  "name": "list_all_brex_transactions",
  "description": "Retrieve a list of all settled transactions for the account.",
  "query_schema": {
    "type": "object",
    "properties": {
      "limit": {
        "type": "string",
        "description": "The number of records to fetch"
      },
      "next_cursor": {
        "type": "string",
        "description": "The cursor to fetch the next set of records. Always send back exactly the cursor value you received without decoding, modifying, or parsing it."
      }
    }
  }
}
```

Notice the explicit instruction for `next_cursor`. LLMs have a tendency to URL-decode or modify base64-encoded cursor strings. By injecting strict natural language instructions directly into the JSON Schema description, Truto prevents the LLM from corrupting the pagination state.

For a deeper dive into this pattern, see our guide on [/auto-generated-mcp-tools-for-ai-agents-a-2026-architecture-guide/](https://truto.one/auto-generated-mcp-tools-for-ai-agents-a-2026-architecture-guide/).

## Step 3: Managing Brex API Rate Limits and Pagination

Brex enforces strict rate limits to protect its infrastructure. When an AI agent attempts to pull thousands of transactions to perform an audit, it will inevitably hit these limits. Brex responds with an `HTTP 429 Too Many Requests` status code and includes rate limit details in the response headers.

Handling this correctly is critical. If the MCP server absorbs the error and returns an empty array to the LLM, the AI agent will assume there are no more transactions and generate an inaccurate financial audit.

Truto normalizes upstream rate limit info into standardized IETF headers (`ratelimit-limit`, `ratelimit-remaining`, `ratelimit-reset`). 

It is important to note that Truto does not retry, throttle, or apply backoff on rate limit errors automatically. When the Brex API returns an `HTTP 429`, Truto passes that error directly to the caller. 

This is a deliberate architectural decision. The caller (the AI agent or the orchestration framework like LangGraph) holds the context of the workflow. The caller is responsible for implementing retry and exponential backoff logic based on the normalized `ratelimit-reset` header. Masking rate limits at the API gateway layer leads to unpredictable LLM timeouts and zombie requests.

Read more about this architectural pattern in our guide on [/best-practices-for-handling-api-rate-limits-and-retries-across-multiple-third-party-apis/](https://truto.one/best-practices-for-handling-api-rate-limits-and-retries-across-multiple-third-party-apis/).

## Step 4: Implementing Method Filtering for Security

Financial APIs carry immense risk. You likely do not want your AI agent to have the ability to arbitrarily issue new corporate cards or delete expense reports without human oversight. 

When configuring an MCP server, you must restrict the toolset to the principle of least privilege. 

Truto supports strict method filtering at the MCP token level. When creating an MCP server for Brex, you can configure the server to only expose `read` operations (`get`, `list`). 

```typescript
// Example: Creating a read-only Brex MCP server via the Truto API
POST /integrated-account/:id/mcp
{
  "name": "Brex Audit Agent MCP",
  "config": {
    "methods": ["read"] // Completely disables create, update, and delete tools
  }
}
```

The platform enforces this configuration at tool generation time. If the `methods` filter is set to `["read"]`, the `create_a_brex_virtual_card` tool is never generated, and the LLM never even knows the capability exists. This eliminates the risk of prompt injection leading to unauthorized financial mutations.

For an extra layer of security, Truto allows you to enable `require_api_token_auth`. By default, an MCP server's token URL is the only authentication required by the protocol. Enabling this flag forces the MCP client to also provide a valid Truto API token in the `Authorization` header, ensuring that possession of the MCP URL alone is insufficient to access the financial data.

## The Build vs. Buy Decision for Brex MCP Servers

When evaluating how to connect your AI agents to Brex, you face a saturated market of integration approaches. Understanding the architectural tradeoffs of each is essential for long-term stability.

### Zapier (Zapier MCP Server)
Zapier positions itself as a no-code way to connect AI agents to Brex via its existing action library. Zapier's MCP server connects AI tools to Zapier's 30,000+ actions. 

The problem with this approach is the heavy middleman orchestration layer. The AI agent interacts with Zapier's abstraction, not the native Brex API. This introduces significant latency, makes debugging nearly impossible when a request fails, and forces your financial data through a third-party orchestration engine that may not meet your compliance requirements.

### Rootly and Custom Open-Source Servers
Rootly built an open-source MCP server specifically for incident management. Brex engineers themselves report that integrating Rootly directly into editors via MCP accelerates incident investigation and increases developer efficiency. This proves the enterprise value of MCP.

However, relying on community-built open-source servers (like `mcp-brex-server`) requires your engineering team to self-host the infrastructure, manually handle the OAuth lifecycle, and constantly maintain the JSON Schemas whenever Brex updates its API. 

### Make.com
Make.com positions itself as a visual workflow builder for Brex. While highly effective for internal, static automation rules (e.g., "If an expense is over $500, send a Slack message"), it lacks the native AI agent tool-calling capabilities of an MCP server. You cannot easily expose Make.com workflows to an LLM as dynamic, self-describing tools.

### Declarative Unified APIs (Truto)
Using a declarative unified API platform like Truto provides the direct API access of a custom build with the zero-maintenance benefits of a managed service. 

Truto automatically generates the MCP tools, handles the OAuth lifecycle, normalizes the rate limit headers, and provides strict method filtering - all without storing your customer's financial data. It allows your engineers to focus on the AI agent's prompt engineering and workflow logic rather than building API glue code.

## Accelerating Financial AI Integrations

The convergence of AI agents and corporate spend management is fundamentally changing how businesses operate. As the market expands toward $5.44 billion by 2030, the companies that win will be those that can securely and reliably connect their LLMs to financial systems of record.

Building a custom Brex integration from scratch requires months of engineering effort dedicated to OAuth state management, schema generation, and rate limit handling. By leveraging a managed MCP infrastructure, you bypass the boilerplate and deliver intelligent financial automation to your customers immediately.

> Stop writing custom API connectors for your AI agents. Partner with Truto to automatically generate secure, production-ready MCP tools for Brex and 100+ other enterprise SaaS platforms.
>
> [Talk to us](https://cal.com/truto/partner-with-truto)