Provides read-only access to Brex financial data including expenses, budgets, spend limits, transactions, card statements, and accounts, with tools for receipt management and expense updates. Supports pagination, filtering, and field projection for controlled data retrieval.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Brex MCP Server show me my approved expenses from last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for the Brex API. Optimized for safe, small, read-only responses with projection and batching.
Fix: Tools now include a permissive inputSchema in the tools list so clients like Claude Code properly display and allow calling tools. No behavior changes to handlers.
Related MCP server: Brex MCP Server
# Install the package
npm install -g mcp-brex
# Add to Claude Code with your API key
claude mcp add brex --env BREX_API_KEY=your_brex_api_key -- npx mcp-brexAdd to your claude_desktop_config.json:
{
"mcpServers": {
"brex": {
"command": "npx",
"args": ["mcp-brex"],
"env": {
"BREX_API_KEY": "your_brex_api_key"
}
}
}
}git clone https://github.com/dennisonbertram/mcp-brex.git
cd mcp-brex
npm install
npm run build
claude mcp add brex --env BREX_API_KEY=your_key -- node build/index.jsbrex://expenses | brex://expenses/{id} | brex://expenses/card | brex://expenses/card/{id}
brex://budgets | brex://budgets/{id}
brex://spend_limits | brex://spend_limits/{id}
brex://budget_programs | brex://budget_programs/{id}
brex://transactions/card/primary | brex://transactions/cash/{id}
brex://docs/usage (compact usage guide for agents)
Notes:
Resources accept ?summary_only=true&fields=id,status,... to control payload size.
Expenses resources auto-expand merchant and budget for readability.
Budgets: get_budgets, get_budget
Spend Limits: get_spend_limits, get_spend_limit
Budget Programs: get_budget_programs, get_budget_program
Expenses (single page): get_expenses
Expenses (paginated): get_all_expenses, get_all_card_expenses
Expense by ID: get_expense, get_card_expense
Card Statements: get_card_statements_primary
Transactions: get_card_transactions, get_cash_transactions (note: no date filter/expand on transactions)
Cash Statements: get_cash_account_statements
Accounts: get_all_accounts, get_account_details
Receipts (write): match_receipt, upload_receipt
Updates (write): update_expense
Always send parameters under arguments (not input). Keep payloads small with pagination and filtering.
Common parameters:
Pagination: page_size (<=50), max_items (<=200 recommended)
Date filtering: start_date, end_date, window_days
Status filtering: status array for expenses/transactions
Amount filtering: min_amount, max_amount for expenses
Merchant filtering: merchant_name for expenses
Expand control: expand array to include nested objects (e.g., ["merchant", "budget"])
Recommended examples:
{
"name": "get_all_card_expenses",
"arguments": {
"page_size": 10,
"max_items": 20,
"start_date": "2025-08-25T00:00:00Z",
"end_date": "2025-08-26T00:00:00Z",
"status": ["APPROVED"],
"min_amount": 100
}
}{
"name": "get_expenses",
"arguments": {
"limit": 5,
"status": "APPROVED"
}
}{
"name": "get_card_transactions",
"arguments": {
"limit": 10,
"summary_only": true,
"fields": ["id", "posted_at", "amount.amount", "amount.currency", "merchant.raw_descriptor"]
}
}{
"name": "get_all_accounts",
"arguments": {
"page_size": 10,
"max_items": 20,
"status": "ACTIVE"
}
}{
"name": "get_transactions",
"arguments": {
"accountId": "acc_123456789",
"limit": 10
}
}{
"name": "get_expenses",
"arguments": {
"limit": 5,
"expand": ["merchant", "user"]
}
}IMPORTANT: Use pagination, filtering, and sorting to control response sizes instead of relying on summaries.
page_size: number — Items per page (recommended: ≤50)
max_items: number — Maximum total items across all pages (recommended: ≤200)
start_date/end_date: string — ISO date range filtering
window_days: number — Split large date ranges into smaller batches
status: string[] — Filter by status (e.g., ["APPROVED", "PENDING"])
min_amount/max_amount: number — Amount-based filtering for expenses
Always use date ranges for bulk requests to avoid huge responses
Use small page sizes (≤50) and reasonable max_items (≤200)
Apply status filters to get only the data you need
Use window_days (e.g., 7) to batch large date ranges
Control nested object expansion with the expand parameter:
Default: expand: [] returns lean objects (~500-1000 tokens each)
With expansion: expand: ["merchant", "budget"] returns full objects (~15K+ tokens each)
Available expand options: merchant, budget, user, department, location, receipts
Test with small limits first before scaling up
Cash endpoints require additional Brex scopes; handle 403s gracefully
Note: Brex transactions endpoints (card and cash) do not support posted_at_start or expand. Retrieve transactions and, if needed, filter client-side by posted_at/posted_at_date.
All amounts from Brex are in cents. This server annotates money fields in tool outputs by default to prevent unit mistakes:
amount_cents: integer (e.g., 100000)
amount_dollars: number in dollars (e.g., 1000.0)
amount_formatted: human-friendly string (e.g., "$1,000.00")
Example (expense purchased_amount):
{
"purchased_amount": {
"amount_cents": 100000,
"amount_dollars": 1000.0,
"amount_formatted": "$1,000.00",
"currency": "USD"
}
}Controls:
format_amounts: "cents" | "dollars" | "both" (default: "both")
include_formatted: boolean (default: true)
include_summary: boolean (default: true) adds meta.summary totals/averages
Only build/, README.md, and LICENSE are published.
MIT — see LICENSE.
Retrieve detailed information for a specific Brex account by account ID. Returns complete account details including current balance, available balance, type, currency, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ID of the Brex account |
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 clearly indicates this is a read operation ('Retrieve') and specifies the scope of returned data, but does not mention authentication requirements, rate limits, error conditions, or whether the data is real-time vs cached. It adds value beyond the schema but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and key parameter, the second enumerates the returned data fields. Every element serves a clear purpose with zero redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no annotations and no output schema, the description provides adequate purpose and output scope. However, it lacks information about authentication, error handling, data freshness, or response structure details that would be helpful given the absence of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'accountId' parameter. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve detailed information'), target resource ('for a specific Brex account'), and key scope ('by account ID'). It distinguishes from sibling tools like 'get_all_accounts' by specifying retrieval for a single account rather than all accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'by account ID' and listing the returned details, which helps differentiate it from tools like 'get_budget' or 'get_transactions'. However, it does not explicitly state when NOT to use this tool or name specific alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all Brex accounts (card and cash) with automatic pagination. Supports status filtering. Returns account details including balances, type, currency, and status. Includes money annotation on balance fields.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Number of items per page (default: 50, max: 100) | |
| max_items | No | Maximum total number of items to retrieve across all pages | |
| status | No | Filter accounts by status |
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 effectively describes key traits: automatic pagination (handling pagination automatically), status filtering capability, and the inclusion of money annotations on balance fields. However, it does not mention rate limits, authentication requirements, or error handling, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by supporting details in a logical flow. Each sentence adds value: fetching accounts, pagination, filtering, return details, and annotations. There is no redundant or wasted text, making it efficiently structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 fairly complete. It covers the purpose, behavior (pagination, filtering), and return details. However, without an output schema, it could benefit from more specifics on the return structure (e.g., format of account details), and it lacks information on error cases or prerequisites, leaving minor gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all parameters (page_size, max_items, status). The description adds minimal value beyond the schema by mentioning 'Supports status filtering', which aligns with the schema's status parameter. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch') and resource ('all Brex accounts (card and cash)'), specifying the scope as all accounts with both card and cash types. It distinguishes from siblings like 'get_account_details' (single account) and 'get_all_card_expenses' (expenses only), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all accounts with filtering, but does not explicitly state when to use this tool versus alternatives like 'get_account_details' for a single account or 'get_budgets' for budget-related data. It mentions automatic pagination and status filtering, providing some context, but lacks clear exclusions or direct sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all card expenses across multiple pages (similar to get_all_expenses but card-specific endpoint). Supports pagination, date filtering, merchant search, and amount filters. Returns complete expense objects with money annotation and summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Number of items per page (default: 50, max: 100) | |
| max_items | No | Maximum total number of items to retrieve across all pages | |
| status | No | Filter card expenses by status | |
| payment_status | No | Filter card expenses by payment status | |
| start_date | No | Filter card expenses created on or after this date (ISO format: YYYY-MM-DD) | |
| end_date | No | Filter card expenses created on or before this date (ISO format: YYYY-MM-DD) | |
| merchant_name | No | Filter card expenses by merchant name (partial match) | |
| window_days | No | Optional batching window in days to split large date ranges | |
| min_amount | No | Client-side minimum purchased_amount.amount filter (in cents) | |
| max_amount | No | Client-side maximum purchased_amount.amount filter (in cents) | |
| expand | No | Fields to expand (e.g., merchant, receipts) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: pagination support, date filtering, merchant search, amount filters, and that it returns complete expense objects with money annotation and summaries. However, it doesn't mention authentication requirements, rate limits, error handling, or whether this is a read-only operation (though 'fetch' implies read). The description adds value but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized at two sentences, front-loaded with the core purpose, and each sentence adds value: the first defines the tool and scope, the second lists features and return format. There's no redundant information, though it could be slightly more structured (e.g., bullet points for features).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema), the description is moderately complete. It covers the tool's purpose, key features, and return format, but lacks details on output structure (beyond 'complete expense objects'), error cases, or performance considerations. Without annotations or output schema, more behavioral context would be beneficial for a tool with many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly with descriptions, constraints, and enums. The description adds marginal value by mentioning 'date filtering, merchant search, and amount filters' which aligns with parameters like start_date, end_date, merchant_name, min_amount, and max_amount, but doesn't provide additional syntax or usage details beyond what the schema specifies. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches card expenses across multiple pages with pagination and filtering capabilities. It specifies 'card-specific endpoint' which distinguishes it from the sibling 'get_all_expenses', though it doesn't explicitly contrast with other card-related tools like 'get_card_expense' or 'get_card_transactions'. The verb 'fetch' and resource 'card expenses' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning it's 'similar to get_all_expenses but card-specific', which suggests when to use this over the general expense tool. However, it doesn't provide explicit guidance on when to use this versus other card-related tools like 'get_card_expense' (singular) or 'get_card_transactions', nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all expenses across multiple pages with automatic pagination handling. Supports date range filtering, amount filtering, status filtering, and merchant search. Returns aggregated results with summary statistics. Use window_days to batch large date ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Number of items per page (default: 50, max: 100) | |
| max_items | No | Maximum total number of items to retrieve across all pages | |
| expense_type | No | Filter expenses by type | |
| status | No | Filter expenses by status | |
| payment_status | No | Filter expenses by payment status | |
| start_date | No | Filter expenses created on or after this date (ISO format: YYYY-MM-DD) | |
| end_date | No | Filter expenses created on or before this date (ISO format: YYYY-MM-DD) | |
| window_days | No | Optional batching window in days to split large date ranges | |
| min_amount | No | Client-side minimum purchased_amount.amount filter (in cents) | |
| max_amount | No | Client-side maximum purchased_amount.amount filter (in cents) | |
| expand | No | Fields to expand (e.g., merchant, receipts) |
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 effectively describes key behaviors: automatic pagination handling, support for multiple filtering types, aggregated results with summary statistics, and batching guidance for large date ranges. It doesn't mention rate limits, authentication requirements, or error handling, but covers the core operational behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences that each add value: first establishes core functionality, second lists filtering capabilities and output, third provides specific usage guidance. No wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 11 parameters and no output schema, the description provides good contextual completeness. It explains the tool's scope, filtering capabilities, pagination behavior, and batching guidance. The main gap is lack of output format details (what 'aggregated results with summary statistics' means), but given the complexity and absence of annotations, it covers most essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds some context by mentioning date range filtering, amount filtering, status filtering, merchant search, and the window_days batching purpose, but doesn't provide additional semantic details beyond what's in the schema. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('fetch all expenses') and resource scope ('across multiple pages with automatic pagination handling'). It distinguishes from siblings like 'get_expense' (singular) and 'get_expenses' (likely less comprehensive) by emphasizing comprehensive retrieval with pagination and filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Use window_days to batch large date ranges') and implies this is for bulk retrieval with filtering. However, it doesn't explicitly state when to use this versus alternatives like 'get_expenses' or 'get_all_card_expenses', which would require more specific sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single budget by its unique ID. Returns complete budget details including spending limits, period configuration, and current status.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | Yes | Unique budget identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return content ('complete budget details including spending limits, period configuration, and current status'), which adds some behavioral context. However, it lacks details on error handling, authentication needs, rate limits, or whether it's read-only (implied by 'Retrieve' but not explicit), leaving significant gaps for a tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and efficient: the first states the purpose and key input, and the second specifies the return details. Every sentence adds essential information with zero waste, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, 100% schema coverage, no nested objects) but lack of annotations and output schema, the description is adequate but incomplete. It covers the purpose and return content but misses behavioral aspects like error cases or operational constraints, making it minimally viable but with clear gaps for an agent to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'budget_id' documented as 'Unique budget identifier'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve'), resource ('a single budget'), and key identifier ('by its unique ID'), distinguishing it from sibling tools like 'get_budgets' (plural) which likely returns multiple budgets. It precisely defines the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'by its unique ID', suggesting this tool is for fetching a specific budget when the ID is known. However, it does not explicitly state when to use this versus alternatives like 'get_budgets' or provide any exclusions or prerequisites, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single budget program by its unique ID. Returns complete program configuration including budget blueprints, employee filters, and automation settings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique budget program identifier |
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 implies a read-only operation ('Retrieve') and specifies the return content ('complete program configuration'), but does not cover aspects like error handling, authentication needs, rate limits, or response format. It adds some context but leaves gaps in behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and efficiently structured in two sentences: the first states the core purpose, and the second details the return content. Every sentence adds value without redundancy, making it appropriately sized and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and return content but lacks details on behavioral aspects like errors or permissions. For a simple retrieval tool, it meets basic needs but could be more comprehensive to fully guide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the single parameter 'id'. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve'), resource ('a single budget program'), and key identifier ('by its unique ID'), distinguishing it from sibling tools like 'get_budget_programs' (plural) which likely returns multiple programs. It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as 'get_budget_programs' for listing programs or 'get_budget' for budget details. It lacks context on prerequisites, exclusions, or specific scenarios, offering only basic functional information without comparative usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List budget program configurations that define automated budget assignment rules. Supports filtering by status and pagination. Returns program details including budget blueprints and employee filters.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of budget programs to return (default: 50) | |
| budget_program_status | No | Filter by budget program status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behaviors: it's a read operation (implied by 'List'), supports filtering and pagination, and returns specific details. However, it misses important context like authentication needs, rate limits, error conditions, or whether it's safe for frequent use, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first states the core purpose, the second adds key features, and the third specifies return details. There's minimal waste, though the second sentence could be slightly more structured (e.g., separating filtering and pagination).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete: it covers purpose, basic behavior, and return content. However, for a tool with 3 parameters and no structured safety hints, it should ideally include more on permissions, error handling, or example usage to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 3 parameters. The description adds marginal value by mentioning filtering by 'status' (matching 'budget_program_status') and 'pagination' (hinting at 'cursor' and 'limit'), but doesn't provide additional syntax, format, or usage details beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('budget program configurations') with specific purpose ('define automated budget assignment rules'), making the tool's function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_budget_program' (singular vs plural) or 'get_budgets', which might cause confusion about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through context ('Supports filtering by status and pagination'), suggesting when to use it for filtered listing. However, it lacks explicit guidance on when to choose this tool over similar siblings (e.g., 'get_budget_program' for a single program vs this for multiple), and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List budget allocations with spending limits and current status. Supports filtering by parent budget and status. Returns paginated budget list with amount details (amount, period, recurrence, limit type).
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of budgets to return (default: 50, max: 100) | |
| parent_budget_id | No | Filter by parent budget ID | |
| spend_budget_status | No | Filter by budget status |
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 adds useful context beyond basic functionality: it mentions pagination ('Returns paginated budget list'), details about return values ('amount details'), and filtering capabilities. However, it doesn't cover aspects like rate limits, authentication needs, error conditions, or whether this is a read-only operation (though 'List' implies reading).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and key features, and the second details return values and pagination. Every sentence adds value without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, filtering, pagination, and return details. However, without annotations or an output schema, it could benefit from more behavioral context (e.g., error handling, rate limits) to fully compensate for the lack of structured data, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds marginal value by mentioning filtering by 'parent budget and status,' which aligns with parameters 'parent_budget_id' and 'spend_budget_status,' but doesn't provide additional syntax or format details beyond what the schema specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List budget allocations with spending limits and current status.' It specifies the verb ('List') and resource ('budget allocations') with additional details about what information is included. However, it doesn't explicitly differentiate from sibling tools like 'get_budget' or 'get_spend_limits,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning filtering capabilities ('Supports filtering by parent budget and status'), which suggests when to use this tool for filtered queries. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'get_budget' or 'get_spend_limits,' nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single card expense by its unique ID. Supports expansion of nested objects. Returns complete card expense details with money annotation. (Deprecated - use get_expense instead)
| Name | Required | Description | Default |
|---|---|---|---|
| expense_id | Yes | Unique card expense identifier | |
| expand | No | Related objects to include in response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'supports expansion of nested objects' and 'returns complete card expense details with money annotation', which provides useful behavioral context about response format and expansion capabilities. However, it doesn't address error conditions, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste: first states core purpose, second adds expansion capability, third provides critical deprecation warning. The deprecation notice is appropriately placed at the end as critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 100% schema coverage but no output schema or annotations, the description provides good context: purpose, expansion capability, return format hint, and critical deprecation status. The main gap is lack of output structure details, but the description compensates reasonably well given the tool's relative simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description mentions 'supports expansion of nested objects' which hints at the 'expand' parameter's purpose, but doesn't add significant semantic value beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'card expense', specifies it's for a single item by unique ID, and distinguishes it from the sibling 'get_expense' by noting this tool is deprecated in favor of that one. This provides specific differentiation from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Deprecated - use get_expense instead', providing clear when-not-to-use guidance. It also distinguishes this from sibling tools by specifying it retrieves a single card expense by ID, not multiple expenses or other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all finalized statements for the primary card account. Supports cursor-based pagination. Returns complete statement objects with period dates, balances, and payment information.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of statements to return (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it lists only finalized statements, supports cursor-based pagination, and returns complete statement objects. However, it doesn't mention rate limits, authentication requirements, or error conditions, leaving some gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: two sentences that efficiently convey purpose, pagination support, and return format without any wasted words. Every sentence adds essential information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description is reasonably complete. It covers what the tool does, pagination behavior, and return content, though it could benefit from mentioning authentication or error handling to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (cursor and limit). The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all finalized statements'), resource ('primary card account'), and scope ('complete statement objects with period dates, balances, and payment information'). It distinguishes from siblings like get_cash_account_statements by specifying 'primary card account' and from get_card_transactions by focusing on statements rather than individual transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving finalized statements from the primary card account, but doesn't explicitly state when to use this tool versus alternatives like get_cash_account_statements or get_card_transactions. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List settled transactions for all card accounts (primary card endpoint). Supports pagination and user filtering. NOTE: Does not support posted_at_start or expand parameters - filter client-side by posted_at_date if needed. Returns transactions with money annotation.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of transactions to return (default: 50, max: 100) | |
| user_ids | No | Optional filter by user IDs |
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 effectively describes key behaviors: it supports pagination and user filtering, specifies what it returns ('transactions with money annotation'), and notes limitations (no posted_at_start or expand parameters). However, it doesn't mention rate limits, authentication needs, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: the first states the core purpose, the second adds behavioral details, and the third provides critical usage notes. Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (list operation with filtering and pagination), no annotations, and no output schema, the description does a good job covering key aspects like scope, behaviors, and limitations. However, it lacks details on return format structure, error cases, or authentication requirements, which could be important for a tool with multiple parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the three parameters (cursor, limit, user_ids). The description adds minimal value beyond the schema by mentioning 'user filtering' which aligns with user_ids, but doesn't provide additional syntax, format details, or context about the parameters. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List settled transactions') and resource ('for all card accounts'), distinguishing it from siblings like get_cash_transactions or get_transactions by specifying it's for card accounts only. The phrase 'primary card endpoint' further clarifies its role in the API hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: it states 'Does not support posted_at_start or expand parameters - filter client-side by posted_at_date if needed,' directing users to client-side filtering instead of expecting server-side support. This helps differentiate from potential sibling tools that might offer those parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List finalized statements for a specific cash account by account ID. Requires cash account scopes. Supports cursor-based pagination. Returns complete statement objects with period details and transaction summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | Cash account identifier | |
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of statements to return (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: it requires specific scopes ('Requires cash account scopes'), supports pagination ('Supports cursor-based pagination'), and describes the return format ('Returns complete statement objects with period details and transaction summaries'). This covers authentication needs, data retrieval behavior, and output structure, though it could add more on rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential behavioral details. Every sentence earns its place: the first defines the action, the second covers prerequisites, the third explains pagination, and the fourth describes returns. It is appropriately sized with zero waste, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 pagination and scopes), no annotations, and no output schema, the description is largely complete. It covers purpose, usage context, behavioral traits, and return content. However, it could be more explicit about error cases or rate limits, and without an output schema, some details on response structure are implied but not fully specified, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (account_id, cursor, limit) with details like default and max values. The description adds marginal value by implying account_id is required for listing statements and cursor is for pagination, but it does not provide additional syntax or format details beyond what the schema offers. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), resource ('finalized statements'), and scope ('for a specific cash account by account ID'), distinguishing it from sibling tools like get_cudget or get_transactions. It specifies the exact type of statements (finalized) and their content (with period details and transaction summaries), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Requires cash account scopes' and 'Supports cursor-based pagination', which guides when to use it (for paginated listing of finalized statements). However, it does not explicitly mention when not to use it or name alternatives (e.g., vs. get_card_statements_primary), leaving some room for improvement in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List settled transactions for a specific cash account. Requires cash account scopes. Supports pagination. NOTE: Does not support posted_at_start or expand parameters - filter client-side by posted_at_date if needed. Returns transactions with money annotation.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | Cash account identifier | |
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of transactions to return (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: authentication requirements ('Requires cash account scopes'), pagination support, parameter limitations, and return format details ('Returns transactions with money annotation'). It provides substantial operational context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four concise sentences, each adding distinct value: purpose statement, authentication requirement, pagination support, parameter limitations, and return format. There's no wasted text, and important information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no annotations and no output schema, the description provides strong context about authentication, pagination, parameter limitations, and return format. It covers most essential operational aspects, though additional details about error conditions or response structure could further enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description adds some value by mentioning client-side filtering for posted_at_date and noting parameter limitations, but doesn't provide additional semantic context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List settled transactions') and resource ('for a specific cash account'), distinguishing it from siblings like get_all_accounts or get_transactions by focusing on cash accounts and settled status. It provides precise scope information that helps differentiate its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('List settled transactions for a specific cash account') and provides important exclusions ('Does not support posted_at_start or expand parameters'), though it doesn't name specific alternative tools for different scenarios. It gives clear context about what the tool does and doesn't support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single expense by its unique ID. Supports expansion of nested objects (merchant, budget, user, department, location, receipts). Returns complete expense details with money annotation.
| Name | Required | Description | Default |
|---|---|---|---|
| expense_id | Yes | Unique expense identifier | |
| expand | No | Related objects to include in response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies that the tool returns 'complete expense details with money annotation' and 'Supports expansion of nested objects' with a list of expandable fields. This gives context about response content and optional functionality beyond basic retrieval. It doesn't mention error handling, permissions, or rate limits, but provides useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded with core functionality and efficiently cover expansion support and return details. Every sentence adds value: the first defines the primary purpose, and the second explains optional features and output characteristics. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a read operation with 2 parameters, 100% schema coverage, and no output schema, the description is reasonably complete. It explains what the tool does, what it returns, and expansion capabilities. However, it lacks details on error cases (e.g., invalid ID handling) and doesn't explicitly confirm it's a safe read operation (though implied by 'Retrieve'), which would be helpful since annotations are absent. Overall, it covers most essential context for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema ('expense_id' as unique identifier, 'expand' as array of related objects). The description adds marginal value by listing the specific expandable objects (merchant, budget, etc.), which clarifies the enum options but doesn't fundamentally enhance understanding beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve'), target resource ('a single expense'), and key identifier ('by its unique ID'). It distinguishes from sibling tools like 'get_all_expenses' by specifying single-item retrieval rather than listing multiple items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Retrieve a single expense by its unique ID,' suggesting this is for fetching specific known expenses rather than searching or listing. However, it doesn't explicitly state when to use alternatives like 'get_all_expenses' for bulk retrieval or 'get_expenses' (if that exists for different filtering). No explicit when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a paginated list of expenses with optional filters for status, type, and amount. Supports expansion of related objects like merchant and budget details. Returns expenses with automatic money annotation (cents, dollars, formatted).
| Name | Required | Description | Default |
|---|---|---|---|
| expense_type | No | Type of expenses to retrieve (CARD, CASH, BILLPAY, REIMBURSEMENT, CLAWBACK, UNSET) | |
| status | No | Filter by expense approval status (DRAFT, SUBMITTED, APPROVED, OUT_OF_POLICY, VOID, CANCELED, SPLIT, SETTLED) | |
| payment_status | No | Filter by payment processing status (NOT_STARTED, PROCESSING, CANCELED, DECLINED, CLEARED, REFUNDING, REFUNDED, CASH_ADVANCE, CREDITED, AWAITING_PAYMENT, SCHEDULED) | |
| limit | No | Maximum number of expenses to return (default: 50, max: 100) | |
| expand | No | Related objects to include in response. Default: [] for minimal size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pagination behavior and automatic money annotation in returns, which is valuable. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'retrieve' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized at two sentences, front-loaded with core functionality. Every sentence adds value: first covers retrieval with filters, second covers expansion and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 5 parameters and 100% schema coverage but no output schema, the description adequately covers the core functionality. However, it lacks details about response structure beyond money annotation, doesn't explain pagination mechanics (e.g., cursor/token), and doesn't address error cases or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions optional filters for status, type, and amount (though 'amount' isn't in the schema) and expansion support, but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a paginated list of expenses with optional filters, distinguishing it from siblings like get_expense (singular) and get_all_expenses (no filters mentioned). However, it doesn't explicitly differentiate from get_all_card_expenses or get_card_expense, which are more specific variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving filtered expense lists and supports expansion of related objects, but provides no explicit guidance on when to use this tool versus alternatives like get_all_expenses or get_expense. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single spend limit by its unique ID. Returns complete spend limit configuration including authorization settings, period recurrence, merchant controls, and current balance.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique spend limit identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'complete spend limit configuration' with details like authorization settings and current balance, which adds useful behavioral context beyond basic retrieval. However, it lacks information on error handling, permissions, or rate limits, which are important for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently details the return content in the second. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly complete. It clearly explains what the tool does and what it returns. However, without annotations or an output schema, it could benefit from more details on error cases or response structure, but it adequately covers the essentials for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single parameter 'id', the schema already documents it as a 'Unique spend limit identifier'. The description adds value by emphasizing that it retrieves 'by its unique ID', reinforcing the parameter's purpose, but does not provide additional syntax or format details. Since there is only one parameter, the baseline is high, and the description adequately complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve'), resource ('a single spend limit'), and key identifier ('by its unique ID'), distinguishing it from sibling tools like 'get_spend_limits' (plural) which likely returns multiple items. It explicitly defines the scope as a single entity retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to fetch a specific spend limit by ID, but it does not explicitly state when to use this tool versus alternatives like 'get_spend_limits' (for multiple limits) or other sibling tools. No exclusions or prerequisites are mentioned, leaving usage context somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List spend limit policies with authorization settings and spending controls. Supports filtering by member user and pagination. Returns detailed limit configurations including base limits, buffer percentages, and merchant category controls.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from previous response | |
| limit | No | Maximum number of spend limits to return (default: 50, max: 100) | |
| member_user_id | No | Filter by member user IDs | |
| parent_budget_id | No | Filter by parent budget ID | |
| status | No | Filter by spend limit status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read operation ('List'), supports filtering and pagination, and describes the return format ('detailed limit configurations including base limits, buffer percentages, and merchant category controls'). However, it doesn't mention rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and key features, the second describes the return format. Every sentence adds value with zero wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description provides good coverage of purpose, behavior, and return format. It adequately compensates for the lack of structured output schema by describing what's returned. However, it could be more complete by mentioning authentication requirements or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning filtering by member user and pagination support, but doesn't provide additional semantic context about parameter usage or interactions. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('spend limit policies') with specific details about what's included ('authorization settings and spending controls'). It distinguishes from sibling tools like 'get_spend_limit' (singular) by indicating it returns multiple policies with filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through mentioning filtering capabilities ('Supports filtering by member user and pagination'), but doesn't explicitly state when to use this tool versus alternatives like 'get_spend_limit' (singular) or other budget-related tools. No specific exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve transactions for a specific Brex account by account ID. Legacy endpoint for general transaction retrieval. Returns transaction list with money annotation.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ID of the Brex account | |
| limit | No | Maximum number of transactions to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'Returns transaction list with money annotation' which provides some output context, but doesn't address important behavioral aspects like pagination, rate limits, authentication requirements, error conditions, or what 'legacy endpoint' implies for reliability/deprecation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a purpose. The first sentence states the core functionality, the second provides important context about it being a legacy endpoint and mentions the return format. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction retrieval tool with no annotations and no output schema, the description is incomplete. It mentions the return includes 'money annotation' but doesn't describe the structure of the transaction list, pagination behavior, error responses, or how this legacy endpoint differs from newer alternatives among the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'by account ID' which is already covered, but doesn't explain format requirements, constraints, or usage patterns for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve transactions for a specific Brex account by account ID' - this is a specific verb+resource combination. However, it doesn't distinguish this tool from its many sibling transaction-related tools (e.g., get_card_transactions, get_cash_transactions), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance - it mentions this is a 'Legacy endpoint for general transaction retrieval' but doesn't explain when to use this tool versus the many sibling transaction tools available. No explicit when/when-not guidance or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a pre-signed S3 URL for uploading a receipt that will be automatically matched with existing expenses. Returns upload URL and receipt matching details. Receipt matching expires after 30 minutes. NOTE: This is a write operation.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_name | Yes | Name of the receipt file (e.g., 'receipt.jpg') | |
| receipt_type | No | Type of the receipt (optional) | |
| notify_email | No | Email address to notify after matching (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a write operation (explicitly noted), returns upload URL and matching details, and has a 30-minute expiration for matching. However, it lacks details on authentication needs, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: first states the core function, second specifies the return values and expiration, third clarifies the operation type. Each sentence adds critical information with zero waste, making it front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description compensates well by explaining the write nature, return values, and expiration. It covers the essential context for a mutation tool, though it could improve by detailing output structure or error handling more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a pre-signed S3 URL for uploading a receipt') and the outcome ('that will be automatically matched with existing expenses'), distinguishing it from sibling tools like 'upload_receipt' which lacks the matching aspect. It precisely defines the verb+resource combination with a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for receipt uploads with matching, but provides no explicit guidance on when to use this tool versus alternatives like 'upload_receipt' (which lacks matching) or other expense-related tools. It mentions the 30-minute expiration as a constraint, but doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update metadata for an existing card expense (memo, category, budget, department, location, custom fields). Returns updated expense object. NOTE: This is a write operation - use cautiously.
| Name | Required | Description | Default |
|---|---|---|---|
| expense_id | Yes | ID of the expense to update | |
| memo | No | Memo text to attach to the expense (optional) | |
| category | No | Category of the expense (optional) | |
| budget_id | No | ID of the budget to associate with the expense (optional) | |
| department_id | No | ID of the department to associate with the expense (optional) | |
| location_id | No | ID of the location to associate with the expense (optional) | |
| custom_fields | No | Custom fields to update (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it's a write operation (mutation), returns an updated expense object, and includes a caution note about careful use. However, it doesn't specify rate limits, authentication requirements, error conditions, or whether changes are reversible. The description adds meaningful context beyond what's in the schema but could be more comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: first states purpose and parameters, second provides behavioral caution. Every sentence earns its place with no wasted words. It's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description does well by stating it's a write operation, listing updatable fields, and noting it returns an updated object. However, it could be more complete by specifying authentication needs, error handling, or what happens to unmentioned fields. For a 7-parameter update tool, it's reasonably complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description lists the metadata fields that can be updated (memo, category, budget, department, location, custom fields), which aligns with parameter names but doesn't add significant semantic meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'existing card expense' with specific metadata fields listed (memo, category, budget, department, location, custom fields). It distinguishes from sibling tools like 'get_expense' or 'get_all_expenses' by being a write operation rather than a read. However, it doesn't explicitly differentiate from potential update alternatives (none appear in sibling list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'existing card expense' and the caution note about being a write operation, suggesting it should be used when metadata needs modification. However, it doesn't provide explicit guidance on when to use this vs. alternatives (no update alternatives in siblings), nor does it mention prerequisites like authentication or permissions. The caution note adds some guidance but isn't specific about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a receipt image (base64-encoded) to a specific card expense. Creates a pre-signed S3 URL, uploads the receipt, and associates it with the expense. Returns upload confirmation. NOTE: This is a write operation.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_data | Yes | Base64-encoded image data | |
| receipt_name | Yes | Name of the receipt file (e.g., 'receipt.jpg') | |
| content_type | Yes | MIME type of the receipt (e.g., 'image/jpeg', 'image/png', 'application/pdf') |
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 effectively describes the multi-step process (creating S3 URL, uploading, associating with expense) and explicitly states 'This is a write operation,' which is crucial for understanding it's a mutation. However, it lacks details on error handling, rate limits, authentication requirements, or what happens if the upload fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by implementation details and a note. It's appropriately sized at three sentences with minimal waste, though the note about being a write operation could be integrated more seamlessly. Each sentence adds value, but there's slight room for tighter phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides a good overview of the write operation and process but lacks completeness. It doesn't explain the return value ('upload confirmation') in detail, such as what data is included or error responses. For a mutation tool with 3 parameters and no structured output, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (receipt_data, receipt_name, content_type) with clear descriptions. The description adds no additional parameter-specific information beyond what's in the schema, such as file size limits or supported formats beyond the examples. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Upload a receipt image'), the resource ('to a specific card expense'), and the technical process ('creates a pre-signed S3 URL, uploads the receipt, and associates it with the expense'). It distinguishes itself from sibling tools like 'match_receipt' or 'update_expense' by focusing on upload functionality rather than matching or updating existing records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'match_receipt' or 'update_expense'. It mentions it's for uploading receipts to expenses but doesn't specify prerequisites, such as whether an expense must already exist or if this creates a new expense. There's no explicit when-not-to-use advice or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
There is significant overlap between tools, such as get_all_expenses and get_all_card_expenses, get_expense and get_card_expense, and multiple transaction retrieval tools (get_card_transactions, get_cash_transactions, get_transactions), which could confuse agents about which to use. However, descriptions clarify some distinctions, like card-specific vs. general endpoints, preventing complete ambiguity.
Tool names follow a highly consistent verb_noun pattern throughout, with all tools using snake_case and clear prefixes like 'get_', 'match_', 'update_', and 'upload_'. This predictability makes it easy for agents to infer functionality from names alone.
With 21 tools, the count is borderline high for a financial management server, potentially overwhelming agents. While Brex's domain (accounts, expenses, budgets, transactions) is broad, the tool set feels heavy, suggesting some consolidation might improve usability without sacrificing coverage.
The server provides comprehensive coverage for Brex's financial operations, including CRUD-like actions for accounts, expenses, budgets, and transactions, plus utilities like receipt matching and uploading. Minor gaps exist, such as no explicit tools for creating or deleting budgets or accounts, but agents can likely work around these with available read and update operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
Read-only bank access for your AI agent. Connects Claude, ChatGPT, Cursor, Gemini, Codex.
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
Read-only zobrx e-commerce data: P&L, orders, inventory, marketplace, tax & shelf insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dennisonbertram/mcp-brex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
