Brex MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like accounts, expenses, budgets, or transactions, with clear naming. However, some overlap exists between 'get_all_expenses' and 'get_expenses' (both list expenses with filters), and 'get_all_card_expenses' and 'get_card_expense' could cause minor confusion due to similar naming but different functions (list vs. single).
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using 'get_' for read operations, 'update_' for modifications, and 'match_'/'upload_' for specific actions. All names are in snake_case with no deviations, making them predictable and easy to parse for an agent.
Tool Count3/5
With 21 tools, the count is on the higher side for a financial management server, bordering on heavy. While it covers many aspects of Brex's domain (accounts, expenses, budgets, transactions, receipts), it might be slightly overwhelming for an agent to navigate efficiently, though not extreme.
Completeness4/5
The tool set provides comprehensive read coverage for core resources like accounts, expenses, budgets, and transactions, with some write/update capabilities (e.g., update_expense, match_receipt). Minor gaps include lack of create/delete operations for budgets or spend limits, but agents can likely work around this for most workflows in the financial domain.
Average 3.1/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it 'Returns full statement objects' which gives some output context, but doesn't describe whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by cursor/limit parameters), or error conditions. The example parameter is helpful but insufficient for comprehensive behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences that directly address purpose and provide a parameter example. There's no unnecessary verbiage, and the information is front-loaded. However, the example could be better integrated into the text rather than appended as a separate fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'statement objects' contain, how pagination works with cursor/limit, error handling, or authentication requirements. The example helps slightly but doesn't compensate for the significant gaps in context needed for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, so the description must compensate. It only provides an example for 'limit' parameter ('Example: {"limit":10}') but doesn't explain what 'cursor' does or the semantics of either parameter. This leaves half the parameters undocumented and provides minimal context for the documented one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'complete statements for the primary card account', making the purpose understandable. It distinguishes from siblings like 'get_cash_account_statements' by specifying 'primary card account', but doesn't explicitly contrast with other statement-related tools. The description is specific but could be more precise about what distinguishes it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_cash_account_statements' or 'get_card_transactions'. It mentions an example parameter value but doesn't explain the context for usage, prerequisites, or exclusions. There's minimal implicit guidance from the tool name alone, but no explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), which implies it's non-destructive, but doesn't mention permissions, rate limits, pagination, or response format. For a tool with two parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, no annotations, no output schema) and multiple sibling tools, the description is incomplete. It doesn't explain return values, error handling, or how it differs from similar tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters ('accountId' and 'limit'). The description adds no additional meaning beyond what the schema provides, such as context for how 'limit' interacts with default behavior. Baseline 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get transactions for a Brex account' clearly states the verb ('Get') and resource ('transactions'), but it's vague about scope (e.g., time range, transaction types) and doesn't distinguish from siblings like 'get_card_transactions' or 'get_cash_transactions'. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_card_transactions' or 'get_cash_transactions'. The description implies usage for any Brex account transactions but offers no context, exclusions, or prerequisites, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'read-only' which is helpful, but doesn't mention pagination behavior (despite a 'cursor' parameter), rate limits, authentication requirements, or what happens when no parameters are provided (all 5 are optional). The example shows output structure but doesn't explain it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences. The first sentence states the purpose clearly, and the second provides a concrete output example. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (all optional, 0% documented), no annotations, and no output schema, the description is insufficient. It doesn't explain how parameters interact, what the default behavior is when no filters are provided, or the pagination mechanism implied by the 'cursor' parameter. The example helps but doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description provides no parameter information beyond what's implied by the example. The example shows 'limit' and 'status' in output but doesn't explain their role as input filters. Parameters like 'cursor', 'parent_budget_id', and 'member_user_id' are completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('spend limits'), making the purpose immediately understandable. It distinguishes from siblings like 'get_spend_limit' (singular) by implying it returns multiple items. However, it doesn't explicitly differentiate from other listing tools like 'get_budgets' or 'get_expenses' in terms of resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_spend_limit' (singular), 'get_budgets', and 'get_expenses', there's no indication of whether this is for bulk retrieval, filtering, or a specific use case. The example shows output format but doesn't help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't clarify if this is a read-only operation, what permissions are required, whether it returns real-time or cached data, or any rate limits. This is a significant gap for a tool that likely accesses sensitive account information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with the core action, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., balance, settings, transactions), the return format, or error handling. For a tool that likely returns structured account data, this leaves the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'accountId' parameter clearly documented. The description doesn't add any additional meaning beyond what the schema provides (e.g., format examples or sourcing guidance), so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a Brex account'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'get_all_accounts' (which likely lists multiple accounts) or 'get_budget' (which focuses on budget data), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an account ID), exclusions, or compare to siblings like 'get_all_accounts' for bulk retrieval or 'get_budget' for financial details, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination and filtering capabilities, but doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what 'complete expense objects' actually contain. For a tool with 11 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three concise parts: a clear purpose statement, a specification of what's returned, and a practical example. Every sentence serves a purpose, and the example is directly relevant. The front-loading of 'LIST: Paginated expenses with filters' immediately communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no annotations, and no output schema, the description is insufficiently complete. While it covers basic purpose and provides an example, it doesn't address the tool's behavioral characteristics, doesn't explain the relationship to sibling expense tools, and doesn't describe the structure of the 'complete expense objects' it returns. The absence of output schema means the description should ideally provide more guidance about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description provides an example showing several parameters in use (page_size, max_items, status, window_days, min_amount), which adds practical context beyond the schema's technical descriptions. However, it doesn't explain parameter interactions or provide additional semantic meaning that isn't already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'LIST: Paginated expenses with filters. Returns complete expense objects.' This specifies the verb (list), resource (expenses), and key characteristics (paginated, filtered, returns complete objects). However, it doesn't explicitly differentiate from sibling tools like 'get_expenses' or 'get_all_card_expenses' which appear to be related expense retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for expense retrieval (get_expenses, get_all_card_expenses, get_card_expense, get_expense), there's no indication of when this comprehensive filtered listing tool is preferred over more specific expense retrieval tools. The example shows usage but doesn't provide contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'read-only', which clarifies it's a safe operation, but lacks details on permissions, error handling, rate limits, or what happens if the ID is invalid. The example adds some context but doesn't fully compensate for the missing annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first ('Get a budget program by ID'), followed by a clarifying note ('read-only') and a concise example. Every sentence earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one required parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or how this tool fits into the broader context of sibling tools, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the 'id' parameter and provides an example format ('bp_123'), adding meaning beyond the schema's basic type definition. However, it doesn't explain the ID's source, format constraints, or validation rules, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a budget program by ID' specifies both the verb ('Get') and resource ('budget program'), with the ID parameter indicating it retrieves a specific instance. However, it doesn't explicitly differentiate from sibling tools like 'get_budget_programs' (plural) or 'get_budget', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'read-only' but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'get_budget_programs' (which might list multiple programs) or 'get_budget' (which might retrieve different data). Usage is implied only by the name and example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the operation is 'read-only', which is useful, and hints at returning 'complete budget program objects', but lacks details on pagination (e.g., cursor usage), error handling, or rate limits. It adds some value but leaves behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by an example. However, the example is somewhat redundant as it repeats parameter names without adding much explanatory value, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on return format, pagination behavior, error cases, and full parameter explanations, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'limit' and 'budget_program_status' in the example, providing minimal context, but does not explain 'cursor' or the meaning of parameters beyond the example. This partial coverage is insufficient for the three undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'budget programs', making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_budget_program' (singular) or 'get_budgets', which might retrieve different data, so it falls short of 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_budget_program' or 'get_budgets', nor does it mention prerequisites or context for usage. It only includes a basic example without explaining selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a 'complete card expense object,' which hints at read-only behavior, but doesn't clarify if it's safe, requires authentication, has rate limits, or what happens on errors. For a tool with no annotations, this is insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a concise example. Every sentence earns its place: the first defines the action, the second specifies the return, and the third provides a practical illustration. It's appropriately sized with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and moderate schema coverage (50%), the description is incomplete. It lacks details on behavioral traits, error handling, and parameter usage beyond the example. For a tool with two parameters and no structured safety hints, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'expense_id' has a description). The description adds minimal value: it implies 'expense_id' is required and provides an example with 'expand' but doesn't explain what 'expand' does or its allowed values. Since schema coverage is moderate, the baseline is 3, and the description doesn't fully compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a single card expense by ID.' It specifies the verb ('Get') and resource ('card expense'), and distinguishes it from siblings like 'get_all_card_expenses' by focusing on a single item. However, it doesn't explicitly differentiate from 'get_expense' (which might be similar), keeping it from 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_all_card_expenses' or 'get_expense', nor does it specify prerequisites or exclusions. This lack of context leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning 'complete transaction objects' and includes an example with pagination and filtering, which adds some behavioral context. However, it lacks details on permissions, rate limits, error handling, or response format, which are critical for a read operation with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and an example, front-loaded with the core purpose. The example is helpful but could be integrated more smoothly. No wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 100% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and provides an example, but lacks behavioral details like response format or error cases. For a list tool with many siblings, more context on differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema: the example illustrates usage of 'limit', 'posted_at_start', and 'expand', but doesn't explain semantics like what 'expand' fields are available or how 'user_ids' filtering works. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('LIST') and resource ('Primary card transactions'), with specificity about returning 'complete transaction objects'. It distinguishes from siblings like 'get_card_expense' (singular) and 'get_card_statements_primary' (statements vs transactions), though not explicitly. However, it doesn't fully differentiate from 'get_cash_transactions' or 'get_transactions' which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'get_cash_transactions', 'get_transactions', and 'get_card_expense', there's no indication of context, prerequisites, or exclusions. The example hints at usage but doesn't explain tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'complete statement objects' and implies pagination via the 'cursor' and 'limit' parameters in the example, but does not explicitly describe pagination behavior, rate limits, authentication needs, or error handling. For a read operation with multiple parameters, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and provide an example. There is no wasted text, and the structure is clear. However, the example is presented as a JSON snippet without explanation, which could be slightly improved for readability, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, pagination behavior, error cases, and differentiation from siblings. Without annotations or an output schema, the agent has insufficient information to reliably invoke this tool or interpret results, making it inadequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds minimal value by mentioning 'account_id' and 'limit' in the example, but does not provide additional semantics beyond what the schema already specifies (e.g., default values or usage context). This meets the baseline for high schema coverage without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get cash account statements by account ID. Returns complete statement objects.' It specifies the verb ('Get'), resource ('cash account statements'), and key identifier ('by account ID'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_cash_transactions' or 'get_card_statements_primary', which could cause confusion in selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions an example with parameters but does not specify prerequisites, contexts, or exclusions. Given sibling tools like 'get_cash_transactions' and 'get_card_statements_primary', the lack of differentiation leaves the agent without clear usage rules, risking incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update an existing card expense' implies a mutation operation, but the description doesn't disclose any behavioral traits: no mention of required permissions, whether the update is reversible, what happens to fields not specified, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with a clear name and good schema documentation. Every word earns its place, and the structure is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context: what permissions are needed, what the response contains, whether the update is atomic, or how errors are handled. The agent has insufficient information to understand the full behavioral implications of invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional parameter semantics beyond what's already in the schema (it doesn't explain parameter relationships, constraints, or examples). With complete schema coverage, the baseline score of 3 is appropriate - the description doesn't add value but doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing card expense'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling update tools (none are listed, but the agent might assume other update tools exist). The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing to identify an expense first), no comparison with other expense-related tools (like 'get_expense' or 'upload_receipt'), and no indication of when this update would be appropriate versus creating a new expense. The agent must infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the upload purpose but doesn't disclose permissions needed, rate limits, whether this creates a new expense record, how matching works, or what happens on failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward upload operation and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after upload (e.g., returns a match ID, creates an expense), error conditions, or system behavior. The agent lacks critical context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation (base64 data, filename, MIME type). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and resource ('a receipt image'), with the purpose 'to match with expenses' providing specific context. It distinguishes from most sibling tools (which are primarily 'get' operations), though it doesn't explicitly differentiate from 'match_receipt' which appears related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'match_receipt' or 'update_expense'. It doesn't mention prerequisites, sequencing, or exclusion criteria, leaving the agent to infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'read-only', which is a useful behavioral disclosure for safety, but lacks details on permissions, rate limits, pagination (implied by 'cursor' parameter), or response format. This is a minimal but adequate disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with zero waste. It front-loads the purpose and includes a practical example, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and a hint for one parameter but misses critical details like parameter meanings, usage context, and behavioral traits (e.g., pagination via 'cursor'), leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only provides an example for the 'limit' parameter, ignoring 'cursor', 'parent_budget_id', and 'spend_budget_status' (including its enum values). This leaves most parameters undocumented, failing to add sufficient meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('budgets'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_budget' or 'get_spend_limits', which appear to be related budget/expense retrieval tools, so it doesn't achieve full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_budget' or 'get_spend_limits'. The example '{"limit":10}' hints at usage but doesn't explain context or exclusions, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'pagination support,' which is useful context beyond the input schema, but fails to describe critical behaviors like rate limits, authentication needs, error handling, or what the return format looks like (e.g., list structure, metadata). For a read operation with pagination, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get all Brex accounts') and adds a key behavioral trait ('with pagination support'). There is no wasted verbiage, and every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (pagination, filtering), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose and hints at pagination but misses details on return values, error cases, and usage context. It's sufficient for a simple read tool but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all three parameters (page_size, max_items, status). The description adds no additional parameter semantics beyond what's in the schema, such as default behaviors or interaction effects. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all Brex accounts'), making the purpose unambiguous. It distinguishes from sibling tools like 'get_account_details' by specifying it retrieves all accounts rather than details of a specific one. However, it doesn't explicitly differentiate from other list tools like 'get_all_expenses' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get_all_accounts' over 'get_account_details' or other sibling tools, nor does it specify prerequisites or exclusions. The mention of 'pagination support' hints at usage for large datasets but isn't explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves and returns an expense object, implying a read-only operation, but doesn't cover permissions, error handling, rate limits, or data format details. The example adds some context but lacks comprehensive 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.
Conciseness5/5
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 a concise example that illustrates usage. Every sentence earns its place, with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic operation and provides an example, but lacks details on return values, error cases, or integration with sibling tools. It's complete enough for a simple retrieval tool but has clear gaps in guidance and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'expense_id' has a description). The description adds value by mentioning the 'expand' parameter in the example, suggesting it can include related data like 'merchant', which isn't documented in the schema. However, it doesn't fully compensate for the lack of schema coverage, as it doesn't explain 'expand' options or constraints beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a single expense by ID. Returns the complete expense object.' It specifies the verb ('Get'), resource ('expense'), and scope ('single'), distinguishing it from sibling tools like 'get_all_expenses' or 'get_expenses' which retrieve multiple expenses. However, it doesn't explicitly differentiate from 'get_card_expense', which might also retrieve a single expense but for cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_expenses' for multiple expenses, 'get_card_expense' for card-specific expenses, or 'update_expense' for modifications. The example hints at usage but doesn't clarify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 authentication requirements ('requires cash scopes') and return format ('complete transaction objects'), but lacks details on pagination behavior (cursor usage), rate limits, error conditions, or what 'complete' entails. This is inadequate for a tool with 5 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating purpose and requirements, and another with an example and return format. It's front-loaded with key information, though the example could be more integrated. No wasted words, but slightly awkward structure with the example embedded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers authentication and return format but misses pagination behavior, error handling, and detailed usage context. For a list tool with siblings, it should better differentiate and explain operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value by providing an example with 'account_id' and 'limit', but doesn't explain parameter interactions, semantics beyond the schema, or clarify the 'expand' field. 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.
Purpose4/5
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 'cash transactions', making the purpose explicit. It distinguishes from siblings like 'get_transactions' by specifying 'cash' scope, though it doesn't explicitly mention how it differs from 'get_cash_account_statements' or 'get_card_transactions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'requires cash scopes', which implies when authentication is needed. However, it doesn't explicitly guide when to use this tool versus alternatives like 'get_transactions' or 'get_cash_account_statements', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'single page' and 'Returns complete expense objects,' which gives some behavioral context about output format and pagination. However, it lacks details on permissions, rate limits, error handling, or whether this is a read-only operation, which is important for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with key information: action (LIST), scope (single page), and output (complete expense objects). The example is helpful but could be slightly more integrated. Overall, it's efficient with little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose and provides an example, but lacks details on behavioral aspects like authentication, error cases, or output structure, which would be beneficial for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly with enums and descriptions. The description adds minimal value by providing an example usage with specific parameters (limit, status, expand), but doesn't explain parameter semantics beyond what the schema provides, aligning with the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing expenses with optional filters and returning complete expense objects. It specifies 'LIST (single page)' which distinguishes it from potential paginated alternatives, though it doesn't explicitly differentiate from sibling tools like 'get_all_expenses' or 'get_expense'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'LIST (single page)' suggesting this is for retrieving a limited set of expenses rather than all expenses, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_all_expenses' or 'get_expense' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal important traits: pagination behavior, that it returns 'complete card expense objects', and provides an example parameter set. However, it doesn't disclose permission requirements, rate limits, error conditions, or what happens with large result sets beyond pagination. The example helps but doesn't substitute for explicit behavioral documentation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at 3 sentences. It's front-loaded with the core purpose, followed by key behavioral notes, and ends with an example. The example is valuable but could be more focused on illustrating the tool's unique aspects rather than showing generic parameters. No wasted words, though the 'no expense_type needed' note seems oddly specific given it's not a schema parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list/read tool with 11 parameters and no output schema, the description is minimally adequate. It covers the basic purpose and mentions pagination and return format ('complete card expense objects'), but doesn't explain what those objects contain, how pagination works in practice, or provide guidance on parameter combinations. With no annotations and no output schema, more behavioral and output context would be helpful for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'no expense_type needed' (which isn't even a parameter in the schema) and provides an example with 4 parameters. The example shows usage patterns but doesn't add semantic meaning beyond what the schema descriptions already provide. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'LIST: Paginated card expenses' with the specific resource 'card expenses'. It distinguishes from siblings like 'get_card_expense' (singular) and 'get_all_expenses' (broader scope) by focusing specifically on card expenses. However, it doesn't explicitly differentiate from 'get_card_transactions' which might be a close alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance with '(no expense_type needed)', suggesting this tool doesn't require that parameter unlike potentially other expense tools. It also mentions pagination which is useful context. However, it doesn't explicitly state when to use this vs alternatives like 'get_card_expense' (singular) or 'get_card_transactions', nor does it provide clear exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds '(read-only)' to indicate non-destructive operation and includes an example ('{"id":"sl_123"}') that clarifies input format. However, it lacks details on permissions, rate limits, error handling, or return format, which are important for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: a single sentence states the purpose and key behavior, followed by a minimal example. Every element (read-only hint, example) adds value without redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 1 parameter with low schema coverage, and no output schema, the description is minimally adequate. It covers the basic operation and input format but lacks details on output structure, error cases, or integration with sibling tools, leaving gaps for a retrieval tool in a financial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by specifying that the 'id' parameter is for a spend limit ID and provides an example format ('sl_123'), which clarifies the expected string pattern beyond the schema's basic type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a spend limit by ID' specifies the verb ('Get') and resource ('spend limit'), and distinguishes it from sibling 'get_spend_limits' (plural) by indicating it retrieves a single item. However, it doesn't explicitly differentiate from other sibling tools like 'get_budget' or 'get_expense' that might also retrieve financial data by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_spend_limits' (for listing all) or other financial retrieval tools, nor does it specify prerequisites or contexts for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the operation is read-only and returns a complete budget object, which is useful behavioral context. However, it lacks details on error handling, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a clarifying note and an example. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 100% schema coverage but no output schema, the description is adequate but could be more complete. It covers the basic operation and return type, but lacks details on response structure or potential edge cases given the context of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'budget_id' parameter. The description adds minimal value with an example but does not provide additional syntax or format details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a budget by ID'), specifying it retrieves a complete budget object. It distinguishes from sibling tools like 'get_budgets' (plural) by focusing on single-budget retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'by ID' and provides an example, but does not explicitly guide when to use this tool versus alternatives like 'get_budgets' or other retrieval tools. 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.
Behavior2/5
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 creation of a pre-signed URL and automatic matching, but doesn't address important behavioral aspects like authentication requirements, rate limits, what happens after matching, whether this is a read-only or write operation, or error conditions. Significant gaps remain for a tool that presumably creates resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core functionality. Every word earns its place - 'pre-signed URL' specifies the output type, 'uploading a receipt' specifies the action, and 'automatically matched with existing expenses' specifies the purpose. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate basic purpose but lacks important contextual information. It doesn't explain what the pre-signed URL looks like, what format the receipt should be in, how matching works, or what happens after matching. The description is complete enough to understand what the tool does but not how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how parameters affect the matching process, provide examples of receipt_type values, or clarify the notification workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 URL for uploading a receipt') and the outcome ('that will be automatically matched with existing expenses'), distinguishing it from the sibling 'upload_receipt' tool which lacks the matching functionality. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context for receipt matching with existing expenses, but doesn't explicitly state when to use this versus alternatives like 'upload_receipt' or when not to use it. The context is clear but lacks explicit sibling differentiation or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-brex-server MCP server](https://glama.ai/mcp/servers/crazyrabbitLTC/mcp-brex-server/badges/card.svg)](https://glama.ai/mcp/servers/crazyrabbitLTC/mcp-brex-server)

Score Badge

Copy to your README.md:

[![mcp-brex-server MCP server](https://glama.ai/mcp/servers/crazyrabbitLTC/mcp-brex-server/badges/score.svg)](https://glama.ai/mcp/servers/crazyrabbitLTC/mcp-brex-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

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

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