Skip to main content
Glama
crazyrabbitLTC

Brex MCP Server

get_budget_program

Retrieve budget program details from Brex by specifying a program ID to access financial planning information.

Instructions

Get a budget program by ID (read-only). Example: {"id":"bp_123"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Implementation Reference

  • Main handler logic for the 'get_budget_program' tool: validates parameters, fetches budget program by ID using BrexClient, formats response as JSON.
    registerToolHandler("get_budget_program", async (request: ToolCallRequest) => {
      try {
        const params = validateParams(request.params.arguments);
        const client = getBrexClient();
        const program = await client.getBudgetProgram(params.id);
        
        return { 
          content: [{ 
            type: "text", 
            text: JSON.stringify({ budget_program: program }, null, 2) 
          }] 
        };
      } catch (error) {
        logError(`Error in get_budget_program: ${error instanceof Error ? error.message : String(error)}`);
        throw error;
      }
    });
  • Type definition and validation for input parameters (requires 'id' as string).
    interface GetBudgetProgramParams { 
      id: string; 
    }
    
    function validateParams(input: unknown): GetBudgetProgramParams {
      const raw = (input || {}) as Record<string, unknown>;
      if (!raw.id) throw new Error("Missing required parameter: id");
      return { 
        id: String(raw.id) 
      };
    }
  • Local registration function that sets up the tool handler using registerToolHandler.
    export function registerGetBudgetProgramById(_server: Server): void {
      registerToolHandler("get_budget_program", async (request: ToolCallRequest) => {
        try {
          const params = validateParams(request.params.arguments);
          const client = getBrexClient();
          const program = await client.getBudgetProgram(params.id);
          
          return { 
            content: [{ 
              type: "text", 
              text: JSON.stringify({ budget_program: program }, null, 2) 
            }] 
          };
        } catch (error) {
          logError(`Error in get_budget_program: ${error instanceof Error ? error.message : String(error)}`);
          throw error;
        }
      });
    }
  • Top-level registration call within registerTools(server) that invokes the tool's register function.
    registerGetBudgetProgramById(server);
  • Input schema exposed in the listTools response for the MCP protocol.
      name: "get_budget_program",
      description: "Get a budget program by ID (read-only). Example: {\"id\":\"bp_123\"}",
      inputSchema: {
        type: "object",
        properties: {
          id: { type: "string" }
        },
        required: ["id"]
      }
    },
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'read-only', which clarifies it's a safe operation, but lacks details on permissions, error handling, rate limits, or what happens if the ID is invalid. The example adds some context but doesn't fully compensate for the missing annotation coverage.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded, with the core purpose stated first ('Get a budget program by ID'), followed by a clarifying note ('read-only') and a concise example. Every sentence earns its place without redundancy or unnecessary elaboration.

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 complexity (a read operation with one required parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or how this tool fits into the broader context of sibling tools, making it inadequate for full agent understanding.

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 0%, so the description must compensate. It mentions the 'id' parameter and provides an example format ('bp_123'), adding meaning beyond the schema's basic type definition. However, it doesn't explain the ID's source, format constraints, or validation rules, leaving gaps in 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 a budget program by ID' specifies both the verb ('Get') and resource ('budget program'), with the ID parameter indicating it retrieves a specific instance. However, it doesn't explicitly differentiate from sibling tools like 'get_budget_programs' (plural) or 'get_budget', leaving some ambiguity about scope.

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 'read-only' but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'get_budget_programs' (which might list multiple programs) or 'get_budget' (which might retrieve different data). Usage is implied only by the name and example.

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