Skip to main content
Glama
crazyrabbitLTC

Brex MCP Server

get_cash_account_statements

Retrieve cash account statements by account ID to access transaction history and financial records. Returns complete statement objects with pagination support for efficient data management.

Instructions

Get cash account statements by account ID. Returns complete statement objects. Example: {"account_id":"cash_acc_123","limit":5}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idYesCash account ID
cursorNoPagination cursor
limitNoItems per page (default 50, max 100)

Implementation Reference

  • The main tool handler function that validates parameters, calls the Brex client to fetch cash account statements, formats the response as JSON, and handles errors.
    registerToolHandler("get_cash_account_statements", async (request: ToolCallRequest) => {
      try {
        const params = validateParams(request.params.arguments);
        const client = getBrexClient();
        const resp = await client.getCashAccountStatements(params.account_id, params.cursor, params.limit);
    
        // Return complete objects without any summarization
        const items = Array.isArray(resp?.items) ? resp.items : [];
    
        return {
          content: [{
            type: "text",
            text: JSON.stringify({
              statements: items,
              meta: {
                count: items.length,
                next_cursor: resp?.next_cursor || undefined
              }
            }, null, 2)
          }]
        };
      } catch (error) {
        logError(`Error in get_cash_account_statements: ${error instanceof Error ? error.message : String(error)}`);
        throw error;
      }
    });
  • JSON schema definition for the tool input parameters as registered with the MCP server.
      name: "get_cash_account_statements",
      description: "Get cash account statements by account ID. Returns complete statement objects. Example: {\"account_id\":\"cash_acc_123\",\"limit\":5}",
      inputSchema: {
        type: "object",
        properties: {
          account_id: { type: "string", description: "Cash account ID" },
          cursor: { type: "string", description: "Pagination cursor" },
          limit: { type: "number", description: "Items per page (default 50, max 100)" }
        },
        required: ["account_id"]
      }
    },
  • Function that registers the get_cash_account_statements tool handler with the tool registry.
    export function registerGetCashAccountStatements(_server: Server): void {
      registerToolHandler("get_cash_account_statements", async (request: ToolCallRequest) => {
        try {
          const params = validateParams(request.params.arguments);
          const client = getBrexClient();
          const resp = await client.getCashAccountStatements(params.account_id, params.cursor, params.limit);
    
          // Return complete objects without any summarization
          const items = Array.isArray(resp?.items) ? resp.items : [];
    
          return {
            content: [{
              type: "text",
              text: JSON.stringify({
                statements: items,
                meta: {
                  count: items.length,
                  next_cursor: resp?.next_cursor || undefined
                }
              }, null, 2)
            }]
          };
        } catch (error) {
          logError(`Error in get_cash_account_statements: ${error instanceof Error ? error.message : String(error)}`);
          throw error;
        }
      });
    }
  • Parameter validation and parsing function for tool inputs.
    function validateParams(input: unknown): GetCashAccountStatementsParams {
      const raw = (input || {}) as Record<string, unknown>;
      if (!raw.account_id) throw new Error("Missing required parameter: account_id");
      const out: GetCashAccountStatementsParams = { account_id: String(raw.account_id) };
      if (raw.cursor !== undefined) out.cursor = String(raw.cursor);
      if (raw.limit !== undefined) {
        const n = parseInt(String(raw.limit), 10);
        if (isNaN(n) || n <= 0 || n > 100) throw new Error("Invalid limit (1..100)");
        out.limit = n;
      }
      return out;
    }
  • BrexClient method that performs the actual API call to retrieve cash account statements.
    async getCashAccountStatements(id: string, cursor?: string, limit?: number): Promise<PageStatement> {
      try {
        const params: Record<string, unknown> = {};
        if (cursor) params.cursor = cursor;
        if (limit) params.limit = limit;
    
        logDebug(`Fetching statements for cash account ${id} from Brex API`);
        const response = await this.client.get(`/v2/accounts/cash/${id}/statements`, { params });
        logDebug(`Successfully fetched ${response.data.items.length} statements for cash account ${id}`);
        return response.data;
      } catch (error) {
        this.handleApiError(error, 'GET', `/v2/accounts/cash/${id}/statements`);
        throw error;
      }
    }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'complete statement objects' and implies pagination via the 'cursor' and 'limit' parameters in the example, but does not explicitly describe pagination behavior, rate limits, authentication needs, or error handling. For a read operation with multiple parameters, this leaves significant gaps in understanding how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with two sentences that directly state the purpose and provide an example. There is no wasted text, and the structure is clear. However, the example is presented as a JSON snippet without explanation, which could be slightly improved for readability, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, pagination behavior, error cases, and differentiation from siblings. Without annotations or an output schema, the agent has insufficient information to reliably invoke this tool or interpret results, making it inadequate for the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds minimal value by mentioning 'account_id' and 'limit' in the example, but does not provide additional semantics beyond what the schema already specifies (e.g., default values or usage context). This meets the baseline for high schema coverage without enhancing parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get cash account statements by account ID. Returns complete statement objects.' It specifies the verb ('Get'), resource ('cash account statements'), and key identifier ('by account ID'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_cash_transactions' or 'get_card_statements_primary', which could cause confusion in selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions an example with parameters but does not specify prerequisites, contexts, or exclusions. Given sibling tools like 'get_cash_transactions' and 'get_card_statements_primary', the lack of differentiation leaves the agent without clear usage rules, risking incorrect tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/crazyrabbitLTC/mcp-brex-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server