The PEX MCP Server provides read-only access to the PEX Card business account platform through 72 tools, enabling AI assistants to retrieve financial, card, and account data.
Business Management: Retrieve business profile, balance, admin details, tags, bank account info, linked businesses, billing information, one-time transfer details, and settings
Card Information: Look up card profiles, spending rules, advanced spending rules, load limit balances, scheduled funding rules, and card orders
Transactions: Fetch paginated business and cardholder transactions with filtering by date, amount, and category; retrieve purchases, declines, attachments, and tags
Account Details: Get cardholder account details, balances, remaining spending limits, and network transactions for both individual cardholders and the entire business
Spending Rulesets: List standard and advanced spending rulesets, see which cards are assigned to each, and look up Merchant Category Code (MCC) categories
Bills & Payments: Search bills, retrieve bill payment details, payment requests, business payments, and payment transfers
Vendors: List vendors, retrieve individual vendor details, and look up vendor card orders
Credit & Invoices: View credit line information, invoices, invoice allocations, and invoice payments
Groups: List cardholder groups and retrieve cardholders belonging to specific groups
Tokens & Provisioning: View current and all authentication tokens, check token provisioning modes, and retrieve issued tokens for cardholders
Callbacks: List available callback subscription types, view all subscriptions, and retrieve individual subscription details
Partner: Retrieve partner details associated with the current business
Key features include input validation with clear error messages, automatic retry logic with exponential backoff for 502/503/504 errors, a 30-second request timeout, and structured JSON logging for debugging.
Provides integration with GitHub Copilot in VS Code, enabling AI assistants to access PEX business account data, cards, transactions, and financial management tools through the PEX External API.
Click on "Deploy 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., "@PEX MCP Server What is my current business account balance?"
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 that provides access to the PEX Card External API. Use this server to let AI assistants like Claude interact with your PEX business account, cards, transactions, and more.
To use the PEX MCP Server, you need a PEX API token. Follow these steps to generate one:
Log in to the PEX Dashboard using your credentials.
Navigate to Profile > Authorized Apps (or go directly to /account/authorized-apps).
Find the PEX MCP Server application and click on it.
Click Generate Token and copy the token value.
Note: Keep your API token secure. Do not commit it to version control or share it publicly.
Related MCP server: Brex MCP Server
Set the following environment variables:
Variable | Required | Description |
| Yes | PEX API base URL (e.g., |
| Yes | Your PEX API token (see Getting Your PEX API Token) |
Add to your claude_desktop_config.json:
{
"mcpServers": {
"pex": {
"command": "npx",
"args": ["-y", "@pexcard_engineering/mcp"],
"env": {
"PEX_API_URL": "https://coreapi.pexcard.com/v4",
"PEX_API_TOKEN": "your-api-token-here"
}
}
}
}macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the MCP server using the Claude Code CLI:
claude mcp add pex -e PEX_API_URL=https://coreapi.pexcard.com/v4 -e PEX_API_TOKEN=your-api-token-here -- npx -y @pexcard_engineering/mcpOr add it manually to your .claude/settings.json:
{
"mcpServers": {
"pex": {
"command": "npx",
"args": ["-y", "@pexcard_engineering/mcp"],
"env": {
"PEX_API_URL": "https://coreapi.pexcard.com/v4",
"PEX_API_TOKEN": "your-api-token-here"
}
}
}
}Add the following to your VS Code settings (.vscode/settings.json or user settings):
{
"github.copilot.chat.mcpServers": {
"pex": {
"command": "npx",
"args": ["-y", "@pexcard_engineering/mcp"],
"env": {
"PEX_API_URL": "https://coreapi.pexcard.com/v4",
"PEX_API_TOKEN": "your-api-token-here"
}
}
}
}Alternatively, create an .mcp.json file in your project root:
{
"servers": {
"pex": {
"command": "npx",
"args": ["-y", "@pexcard_engineering/mcp"],
"env": {
"PEX_API_URL": "https://coreapi.pexcard.com/v4",
"PEX_API_TOKEN": "your-api-token-here"
}
}
}
}Tip: When using
.mcp.json, add it to your.gitignoreif it contains your actual token, or use environment variable references to keep secrets out of source control.
Tool | Description |
| Get business profile details including name, address, phone, and status |
| Get business account balance |
| Get list of all business administrators |
| Get a specific business administrator by ID |
| Get all business tags |
| Get a specific business tag by ID |
| Get linked businesses |
| Get business bank account details |
| Get business one-time transfer details |
| Get the current user's business profile |
| Get business billing information for a specific month |
| Get business settings |
Tool | Description |
| Get card profile/details by card account ID |
| Get spending rules for a specific card |
| Get advanced spending rules for a specific card |
| Get remaining card load limit for a specific card |
| Get scheduled funding rules for a specific card |
| Get a specific card order by ID |
| Get card orders within an optional date range |
Tool | Description |
| Get paginated business transactions with filters |
| Get a specific business transaction by ID |
| Get paginated cardholder transactions |
| Get a specific cardholder transaction by ID |
| Get paginated cardholder purchases |
| Get a specific cardholder purchase by ID |
| Get paginated cardholder declines |
| Get all attachments for a transaction |
| Get a specific attachment for a transaction |
| Get tags for a specific transaction |
Tool | Description |
| Get cardholder account details by ID |
| Get advanced cardholder account details by ID |
| Get all cardholder account details for the business |
| Get account balance for a specific cardholder |
| Get remaining spending limits for a cardholder |
| Get network transactions for the business |
| Get network transactions for a specific cardholder |
| Get transaction details for a specific transaction |
| Get transaction details for the business |
| Get all cardholder transactions within a date range |
Tool | Description |
| Get all spending rulesets for the business |
| Get a specific spending ruleset by ID |
| Get cards assigned to a spending ruleset |
| Get all advanced spending rulesets |
| Get a specific advanced spending ruleset by ID |
| Get cards assigned to an advanced spending ruleset |
| Get Merchant Category Code (MCC) categories |
Tool | Description |
| Get bill payment details by bill ID |
| Get payments for a specific bill |
| Get a specific bill payment request by ID |
| Search bills with optional filters |
Tool | Description |
| Get paginated list of vendors with filters |
| Get a specific vendor by ID |
| Get vendor card order details by order ID |
Tool | Description |
| Get paginated list of business payments |
| Get a specific payment transfer by ID |
| Get a specific payment request by ID |
Tool | Description |
| Get credit line information for the business |
| Get business invoices starting from a given date |
| Get allocations for a specific invoice |
| Get payments for a specific invoice |
Tool | Description |
| Get all cardholder groups for the business |
| Get cardholders belonging to a specific group |
Tool | Description |
| Get details of the current authentication token |
| Get all tokens for the authenticated user |
| Get basic token details for the authenticated user |
| Get the business token provisioning mode |
| Get token provisioning mode for a cardholder |
| Get issued tokens for a specific cardholder |
Tool | Description |
| Get available callback subscription types |
| Get all callback subscriptions for the business |
| Get a specific callback subscription by ID |
Tool | Description |
| Get partner details for the current business |
Full API Coverage: 72 tools covering all GET endpoints of the PEX External API
Input Validation: All parameters validated with clear error messages
Retry Logic: Automatic retries with exponential backoff on 502/503/504 errors
Request Timeout: 30-second timeout prevents hanging requests
Structured Logging: JSON logs to stderr for debugging (stdout reserved for MCP)
Rich Documentation: All tool parameters include descriptions, valid values, and constraints
Once connected, you can ask Claude things like:
"What's my business account balance?"
"Show me all transactions from last week over $100"
"List all cards with their spending limits"
"What are the spending rules for card 12345?"
"Show me pending payments"
MIT
Get account balance for a specific cardholder
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full disclosure. It only implies read-only access via the verb 'Get' but fails to describe return format (currency, pending vs available balance), caching behavior, or real-time guarantees.
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?
Single sentence, front-loaded with the action. Efficient structure but arguably too minimal—it sacrifices necessary behavioral details for brevity.
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?
Adequate for a single-parameter read operation, but lacks return value specification (balance format, currency) since no output schema exists. Does not compensate for missing annotations with additional operational 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 has 100% coverage with 'Account ID' clearly documented. The description adds minimal context by linking the ID to a 'specific cardholder', but does not elaborate on ID format or validation beyond 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?
Uses specific verb 'Get' and resource 'account balance'. However, it fails to distinguish from siblings like 'pex_get_account_details' or 'pex_get_account_remaining_limits', and uses 'cardholder' while the parameter is 'Account ID', creating slight ambiguity.
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?
Provides no guidance on when to use this tool versus alternatives like 'pex_get_account_details' or 'pex_get_all_account_details'. No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cardholder account details by account ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden of behavioral disclosure. It implies read-only via 'Get' but provides no information about what fields/data are returned, error handling for invalid IDs, 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?
Single sentence is appropriately brief and front-loaded with the verb. However, given the lack of output schema and numerous sibling tools, the extreme brevity under-provides context rather than demonstrating efficient precision.
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?
Inadequate given the tool ecosystem complexity. With no output schema and many similar account-related siblings, the description must clarify what specific data 'details' includes to enable correct tool selection, which it fails to do.
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 coverage and only one parameter (id), the baseline score is appropriate. The description mentions 'by account ID' which aligns with the schema, adding minimal semantic confirmation but no additional syntax or format guidance beyond 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?
States specific verb (Get) and resource (cardholder account details) with lookup key (account ID), but fails to distinguish from numerous siblings like pex_get_advanced_account_details, pex_get_all_account_details, and pex_get_account_balance, leaving tool selection ambiguous.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., when to use pex_get_account_balance for just balance, or pex_get_advanced_account_details for richer data). No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get remaining spending limits for a specific cardholder
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It fails to indicate that this is a read-only operation, what happens if the ID is invalid, or what types of limits are included (daily, monthly, per-transaction).
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?
Single sentence, appropriately front-loaded with the action, and contains no redundant or wasted words. The length is suitable for a one-parameter read operation.
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 simple tool with one parameter and no output schema, the description is minimally viable. However, it should clarify the relationship between the 'Account ID' parameter and the 'cardholder' mentioned in the description, and specify what spending limit categories are returned.
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 ('Account ID'), the schema adequately documents the parameter. The description implies the ID refers to a cardholder's account but does not add semantic context about ID format, valid ranges, or where to obtain this identifier.
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 uses a specific verb ('Get') and resource ('remaining spending limits') and scopes it to a 'specific cardholder'. However, it does not explicitly distinguish this from sibling tools like 'pex_get_card_load_limit_remaining' or clarify whether account-level limits differ from card-level limits.
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?
No guidance provided on when to use this tool versus alternatives. Given the presence of siblings like 'pex_get_account_balance', 'pex_get_card_load_limit_remaining', and 'pex_get_spending_ruleset', the description should indicate when this specific endpoint is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get advanced cardholder account details by account ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses only the basic read operation. It fails to explain what data fields 'advanced' encompasses, whether the operation is idempotent, or any rate-limiting concerns.
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?
Extremely concise at 9 words with front-loaded verb. However, extreme brevity contributes to under-specification regarding behavioral traits and sibling distinctions, preventing a 5.
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?
With no output schema and no annotations, the description should disclose the return content to distinguish 'advanced' details from standard ones. It fails to compensate for these missing structured fields, leaving significant 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?
Input schema has 100% coverage with the 'id' parameter fully described as 'Account ID'. The description references 'by account ID' reinforcing usage but adds no additional semantic details (e.g., ID format, where to find it) beyond 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?
States a clear verb ('Get') and resource ('advanced cardholder account details'), but does not explain what distinguishes 'advanced' details from the sibling 'pex_get_account_details', leaving sibling differentiation to naming convention only.
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?
Provides no guidance on when to use this 'advanced' version versus the standard 'pex_get_account_details' or 'pex_get_all_account_details' siblings, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific advanced spending ruleset by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ruleset ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Get' implies a read operation, there's no disclosure of error behavior (e.g., 404 vs empty response), rate limits, or whether the operation is idempotent/safe.
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?
Single sentence, front-loaded, no redundancy. However, given the rich ecosystem of similar tools, it may be underspecified rather than optimally 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?
Sufficient for a simple lookup tool with one required parameter. Given no output schema exists and the tool has many similarly-named siblings, additional context (e.g., sample use case) would improve 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?
Schema description coverage is 100% ('Ruleset ID'), so baseline applies. Description adds 'by ID' which confirms the usage pattern but adds minimal semantic depth beyond the schema's 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?
Clear verb (Get), resource (advanced spending ruleset), and lookup method (by ID). Aligns with naming convention to distinguish from 'spending_ruleset' (non-advanced) and 'list_advanced_spending_rulesets' (plural), though it doesn't explicitly clarify what makes it 'advanced'.
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?
Provides no guidance on when to use this single-item lookup versus the list variant (pex_list_advanced_spending_rulesets), nor mentions that an ID must likely be obtained from a list operation first. No prerequisites or error conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cards assigned to a specific advanced spending ruleset. Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ruleset ID | |
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (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. It discloses pagination behavior, which is critical for result-set handling. However, it omits other behavioral traits: error handling (what happens if the ruleset ID doesn't exist), whether the operation is read-only (implied but not explicit), or rate limiting concerns.
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?
Two sentences with zero waste: the first states the core operation, the second states the pagination behavior. Front-loaded and appropriately sized for a simple list endpoint with three parameters.
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 simplicity (3 parameters, 100% schema coverage) and lack of output schema, the description covers the essential operation and pagination. However, it fails to address the 'advanced' qualifier's meaning or how this tool fits among the numerous spending ruleset-related siblings, leaving contextual 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?
The input schema has 100% description coverage ('Ruleset ID', 'Page number', 'Results per page'), so the schema fully documents parameter semantics. The description doesn't add additional context about the 'id' parameter referring specifically to an advanced ruleset ID, but with complete schema coverage, baseline 3 is appropriate.
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 uses a specific verb ('Get') + resource ('cards') + scope ('assigned to a specific advanced spending ruleset'), clearly identifying the operation. However, it doesn't clarify what distinguishes an 'advanced' spending ruleset from a regular one (vs. sibling pex_get_spending_ruleset_cards) or explain the relationship to pex_get_advanced_spending_ruleset.
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?
Only mentions that results are paginated. Provides no guidance on when to use this tool versus pex_get_spending_ruleset_cards (regular vs advanced) or pex_get_card_advanced_spend_rules (the inverse relationship), nor does it mention any prerequisites like requiring a valid ruleset ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cardholder account details for the business. Results are paginated to handle large datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (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 of behavioral disclosure. It successfully notes pagination behavior, but lacks other critical details such as rate limits for bulk fetching, authentication requirements, or what the returned 'details' specifically include (fields, format).
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?
Two sentences with no wasted words. The first sentence states purpose; the second states key behavioral trait (pagination). Information is appropriately 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?
Adequate for a simple pagination wrapper with 2 parameters, but gaps remain. Without an output schema, the description should ideally specify what constitutes 'account details' and how they differ from the 'advanced' sibling's output to aid selection.
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%, establishing a baseline of 3. The description mentions pagination which contextualizes the page/pageSize parameters, but does not add syntax details, valid ranges, or semantics beyond what the schema already provides.
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 identifies the action ('Get'), resource ('cardholder account details'), and scope ('all'/'for the business'). It distinguishes itself from the singular 'pex_get_account_details' by specifying 'all', though it doesn't clarify how the detail level compares to 'pex_get_advanced_account_details'.
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 mentions pagination for 'large datasets' but provides no explicit guidance on when to use this bulk retrieval tool versus the singular 'pex_get_account_details' or the 'advanced' variant. No alternatives or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cardholder transactions within a date range. Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | Start date (ISO 8601) | |
| endDate | Yes | End date (ISO 8601) | |
| includePendings | No | Include pending transactions | |
| includeDeclines | No | Include declined transactions | |
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It successfully notes that 'Results are paginated,' which is critical for API consumption. However, it lacks other important behavioral context such as maximum date range limits, rate limiting, data retention policies, or whether this retrieves transactions across all cardholders or requires specific authorization scopes.
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 consists of two efficient sentences: the first establishes the core purpose and the second discloses the pagination behavior. There is no redundant or wasted text; every word serves a functional purpose for the agent's 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 100% schema coverage and lack of output schema, the description provides the minimum necessary context (pagination) for a bulk-list operation. However, it fails to address the specific differentiation from similar sibling tools or operational constraints (e.g., maximum lookback periods), leaving gaps that could lead to incorrect tool selection.
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%, documenting all six parameters including date formats and pagination controls. The description text mentions 'within a date range,' which aligns with the required parameters, but adds no additional semantic value regarding parameter relationships, constraints, or syntax beyond what the schema already provides. Baseline 3 is appropriate for high-coverage schemas.
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 (Get), resource (cardholder transactions), and primary scope (within a date range). However, while it uses 'Get all' to suggest bulk retrieval, it does not clearly distinguish from the similar sibling tool 'pex_get_cardholder_transactions' (without 'all'), leaving ambiguity about the specific use case for this variant versus the standard plural version.
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 mentions pagination behavior but provides no guidance on when to select this tool versus alternatives like 'pex_get_cardholder_transactions' (non-'all' version) or 'pex_get_cardholder_purchases'. There are no explicit when-to-use criteria, prerequisites, or exclusions mentioned despite the crowded sibling namespace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of basic token details for the authenticated user and app
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 establishes the authentication context ('authenticated user and app') and data granularity ('basic token details'), but lacks critical behavioral information such as whether the operation is read-only, pagination behavior, rate limits, or security sensitivity of the token data.
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 a single, efficient sentence that front-loads the action ('Get') and immediately clarifies the object and scope. No words are wasted, and the length is appropriate for a zero-parameter retrieval tool.
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 simplicity (zero parameters, no annotations, no output schema), the description adequately covers the basic operation but leaves gaps regarding return value structure and fails to differentiate from the numerous sibling token-retrieval tools in the API surface.
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 zero parameters, which per evaluation guidelines establishes a baseline score of 4. The description appropriately requires no additional parameter explanation since none exist.
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 uses a specific verb ('Get') and resource ('basic token details') and clarifies the scope ('for the authenticated user and app'). However, it does not distinguish from sibling tools like 'pex_get_current_token', 'pex_get_issued_tokens', or 'pex_list_tokens', leaving ambiguity about which token retrieval tool to use.
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. There is no mention of prerequisites, exclusion criteria, or explicit references to sibling tools that perform similar token-related functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bill payment details by bill ID
| Name | Required | Description | Default |
|---|---|---|---|
| billId | Yes | Bill ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden of behavioral disclosure. Beyond implying a read operation via 'Get', it reveals nothing about error handling (what if bill ID invalid?), data sensitivity, rate limits, or return structure.
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?
Extremely concise (6 words) and front-loaded with verb. Efficient for a simple tool, though given the rich sibling context with many bill-related endpoints, slightly more detail would improve clarity without sacrificing structure.
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 retrieval tool without output schema, description minimally meets needs by identifying the returned resource type. However, gaps remain regarding behavioral traits and sibling differentiation that would be necessary for robust agent operation.
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 has 100% coverage (billId described as 'Bill ID'), establishing baseline of 3. Description mentions 'by bill ID' but adds no additional semantic detail like ID format, source, or constraints beyond what schema provides.
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?
Clear verb+resource+filter ('Get bill payment details by bill ID'), specifying exactly what resource is retrieved. However, it lacks differentiation from sibling tools like pex_get_bill_payments and pex_search_bills, which could confuse selection.
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?
No explicit guidance on when to use this versus pex_get_bill_payments (plural) or pex_search_bills. No mention of prerequisites like bill ID format or source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific bill payment request by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Bill payment request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States retrieval operation but discloses nothing about return structure, error handling (e.g., invalid ID), idempotency, or side effects. 'Get' implies read-only but this should be explicit without readOnlyHint annotation.
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?
Seven words, front-loaded verb, zero redundancy. Appropriate length for single-parameter retrieval tool.
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?
Adequate for a simple get-by-ID operation with no output schema, but lacks contextual differentiation within this large API surface (what exactly is a 'bill payment request' vs 'bill' or 'payment'?).
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 has 100% description coverage (id: 'Bill payment request ID'). Description reinforces the 'by ID' lookup pattern but adds no semantic nuance beyond the schema, which is sufficient baseline given complete 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?
States specific verb (Get) and resource (bill payment request) with scope (by ID). However, fails to distinguish from similar siblings like pex_get_payment_request or pex_get_bill_payments, leaving ambiguity about the entity type.
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?
Provides no guidance on when to use this tool versus alternatives like pex_get_bill_payments (list) or pex_get_payment_request. No prerequisites or error conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get payments for a specific bill
| Name | Required | Description | Default |
|---|---|---|---|
| billId | Yes | Bill ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies read-only operation, but lacks disclosure on pagination, response format (list vs single object), or behavior when no payments exist. Insufficient for a multi-return 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?
Extremely brief at 6 words. No wasted language, but borderline underspecified given lack of output schema and behavioral details. Front-loaded structure is appropriate.
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?
Adequate for a simple single-parameter getter, but lacks description of return structure given no output schema exists. Does not mention relation to pex_get_bill or payment request 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 coverage is 100% with billId described as 'Bill ID'. Description adds no parameter syntax or semantics beyond schema, but baseline 3 applies since schema is fully documented.
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?
Clear verb (Get), resource (payments), and scope (for a specific bill). Implicitly distinguishes from sibling pex_get_payments (general) by specifying 'for a specific bill', though it does not explicitly name alternatives.
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?
No explicit guidance on when to use this versus pex_get_payments or pex_get_bill_payment_request. No prerequisites or conditions mentioned despite the presence of similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific business administrator by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Administrator ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Beyond 'Get' implying a read operation, it reveals no behavioral traits: no mention of idempotency, error handling for invalid IDs, rate limits, or what data is returned.
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?
Single sentence of 7 words with verb-first structure. Every word earns its place: 'Get' (action), 'specific' (scope distinction), 'business administrator' (resource), 'by ID' (parameter hint). No redundancy or waste.
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?
Adequate for a single-parameter tool with complete schema coverage, but lacks output schema and description reveals nothing about the return structure or absence behavior. For a lookup tool with no output schema hints, this leaves the agent unprepared for the response format.
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 has 100% coverage with clear description 'Administrator ID'. The description mentions 'by ID' which aligns with the parameter but adds no additional semantic context (e.g., format requirements, where to find the ID). Baseline 3 appropriate given complete 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?
Clear verb 'Get' with specific resource 'business administrator'. Using 'specific...by ID' effectively distinguishes this from sibling tool 'pex_get_business_admins' (plural), indicating this is for individual lookup rather than listing.
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?
Implies usage context through 'by ID' (use when you have a specific identifier), but lacks explicit guidance on when to use this versus the plural 'pex_get_business_admins' endpoint, and mentions no prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all business administrators
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. 'Get list' implies read-only access but fails to address pagination (critical for 'all' resources), response format, caching behavior, or rate limiting considerations.
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?
Six-word description is appropriately front-loaded with zero redundancy. Each word serves essential purpose—though extreme brevity sacrifices necessary behavioral context.
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?
Minimal viable description for zero-parameter tool. Given absence of output schema and annotations, lacks necessary disclosure about pagination behavior, return structure, or data volume expectations when retrieving 'all' administrators.
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?
Input schema has zero parameters, establishing baseline 4. Description confirms no filtering by stating 'all' business administrators, which aligns with empty schema and prevents parameter confusion.
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?
States specific action (Get) and resource (business administrators) clearly. Uses 'all' and plural 'admins' which implicitly distinguishes from sibling tool 'pex_get_business_admin' (singular), though it doesn't explicitly clarify when to use the list versus single retrieval.
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?
Provides no guidance on when to use this tool versus the singular 'pex_get_business_admin' or other user management tools. No prerequisites, filtering options, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business account balance
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 but reveals almost nothing. It does not indicate whether the balance is real-time or cached, response format, possible error states, or rate limiting constraints.
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 single sentence is front-loaded with the verb and wastes no words, but its extreme brevity borders on under-specification given the lack of structured metadata.
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?
Despite low parameter complexity, the description omits critical context: it does not characterize the return value (currency, available vs. pending balance), nor does it clarify the relationship between 'business' and 'account' scopes evident in the sibling tool list.
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 zero parameters and 100% schema coverage (vacuous), the baseline score applies. The description does not need to elaborate on inputs since none exist.
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 states the basic action (Get) and resource (business account balance), but fails to distinguish from the sibling tool 'pex_get_account_balance'. Without explaining what constitutes a 'business' account versus a regular account, the agent cannot confidently select between these similar 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?
No guidance provided on when to use this tool versus alternatives like 'pex_get_account_balance', nor any mention of prerequisites such as business authentication context or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business bank account details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Get' implies a read-only operation, the description omits auth requirements, rate limits, pagination behavior, or what specific bank account details are returned (e.g., routing numbers, account numbers, status).
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 four-word description is appropriately brief but under-delivers given context. With numerous sibling tools and no output schema, the extreme brevity constitutes underspecification rather than efficient communication—it leaves critical disambiguation work undone.
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?
While the tool has low structural complexity (no params, no output schema), the description is insufficient for the contextual density. It fails to define 'business bank account' scope (primary operating account? virtual accounts? linked external accounts?) or explain return values, which is critical given the absence of an 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?
Input schema contains zero parameters. Per evaluation rules, zero-parameter tools receive a baseline score of 4, as there are no parameter semantics to clarify beyond the schema itself.
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 restates the tool name with slight expansion ('Get business bank account details' vs 'pex_get_business_bank_account'), identifying the verb and resource. However, it fails to distinguish this tool from siblings like 'pex_get_business_balance', 'pex_get_business_profile', or 'pex_get_business_billing', leaving ambiguity about what specific 'details' this returns versus those alternatives.
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?
No explicit guidance is provided on when to use this tool versus alternatives. Given the dense sibling namespace (pex_get_business_balance, pex_get_account_details, etc.), the description offers no criteria for selecting this specific endpoint over other business-related getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business billing information for a specific month. Current month values are estimates; finalized after billing cycle ends.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes | Month (1–12) | |
| year | Yes | Year (e.g. 2025) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses the important freshness trait (estimates vs. finalized), but omits other expected behaviors like error handling for future months, rate limits, or data retention periods.
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?
Two efficient sentences with zero waste. Critical behavioral warning about estimates/finalized values is included without verbosity. Purpose 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?
Adequate for a simple 2-parameter read operation. The estimate warning adds necessary context. However, given no output schema and no annotations, it could clarify expected return structure or distinguish business billing scope from other billing endpoints.
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 coverage is 100% with clear parameter descriptions (month 1-12, year format). The description mentions 'specific month' but does not add semantic constraints (e.g., 'must be current or past month', 'billing cycle month') beyond the schema baseline.
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?
Clear verb 'Get' and resource 'business billing information' with scope 'for a specific month'. However, given siblings like 'pex_get_bill' and 'pex_search_bills', it does not explicitly clarify when to use this monthly aggregation versus specific bill retrieval.
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?
Provides temporal guidance that 'Current month values are estimates; finalized after billing cycle ends', which warns about data freshness. However, lacks explicit guidance on when to choose this over 'pex_get_bill' or other billing-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get linked businesses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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, yet reveals nothing about scope, permissions, pagination, or what constitutes a 'linked' business. It adds no context beyond the tool name itself.
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?
While brief (three words), this represents under-specification rather than effective conciseness. The single phrase fails to earn its place by providing actionable information, resulting in a description that is too minimal to be useful.
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 ambiguity of the 'linked' concept and the absence of an output schema, the description is inadequate. It leaves the agent with no understanding of return values, business logic, or how this tool fits into the broader business/account management workflow.
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 contains zero parameters. Per the rubric, 0 parameters warrants a baseline score of 4, as there are no parameter semantics to describe beyond the empty 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 'Get linked businesses' is tautological, essentially restating the tool name ('pex_get_business_linked') without clarifying the entity relationship. While it identifies the resource (businesses), it fails to specify what 'linked' means (linked to what/whom?) or how this differs from siblings like 'pex_get_business_profile' or 'pex_get_business_settings'.
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?
Zero guidance is provided. Among dozens of sibling 'pex_get_business_*' tools, the description offers no criteria for when to invoke this specific endpoint versus alternatives, nor does it indicate prerequisites or constraints for retrieving linked businesses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current user's business profile
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the full burden on the description. The text provides no behavioral details beyond the basic action, such as what data the profile contains, whether the data is sensitive, caching behavior, or rate limits. This leaves significant gaps for an agent understanding side effects or return values.
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 a single, efficient sentence with no wasted words. It is appropriately front-loaded with the action verb and conveys the complete intent immediately without requiring the agent to parse complex clauses or irrelevant details.
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 simplicity (zero parameters, no nested objects) and lack of output schema or annotations, the description covers the basic contract adequately but minimally. It fails to describe what constitutes a 'business profile' or what the return payload includes, leaving agents to infer the response structure.
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 contains zero parameters, which per the guidelines establishes a baseline score of 4. The description neither adds nor subtracts value regarding parameters since there are none to document, and the empty schema is inherently self-explanatory.
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 provides a clear verb ('Get') and resource ('current user's business profile'). It interprets the 'my' in the tool name as 'current user', clarifying the scope. While it doesn't explicitly contrast with the sibling tool 'pex_get_business_profile', the 'current user' phrasing implicitly distinguishes this as the authenicated user endpoint versus a general lookup.
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 offers implied usage guidance through the phrase 'current user's', suggesting this tool retrieves the authenticated user's own profile rather than arbitrary profiles. However, it lacks explicit guidance on when to use this versus 'pex_get_business_profile' or whether prerequisites like authentication tokens are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business one-time transfer details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Get' implies a read operation, the description confirms nothing about safety, side effects, rate limits, or what determines which transfer details are returned given zero input parameters.
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?
Though brief, this represents under-specification rather than true conciseness. The single sentence fails to earn its place by providing no actionable information beyond the function name, wasting the opportunity to add critical context.
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 zero-parameter getter with no output schema and no annotations, the description is insufficient. It does not clarify what business context is required, what scope of transfers are retrieved (all? current? pending?), or how the returned data is structured.
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?
Input schema contains zero parameters (100% coverage of empty set). Per calibration rules, 0 params warrants a baseline score of 4. No parameter semantics are required in 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 'Get business one-time transfer details' is tautological, merely restating the tool name with slight expansion. It fails to specify what constitutes a 'one-time transfer' in this context or how it differs from sibling tools like pex_get_payment_transfer.
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?
No guidance provided on when to use this tool versus alternatives (e.g., pex_get_payment_transfer), nor any prerequisites or conditions for invocation. The user has no criteria for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business profile details including name, address, phone, and status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It compensates partially by listing specific fields returned (name, address, phone, status), hinting at the data structure. However, it omits mutation behavior (implied read-only), authorization requirements, error conditions, and rate limit characteristics.
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?
Single sentence of nine words with zero redundancy. Every word earns its place: the verb establishes action, the resource identifies the entity, and the field list provides immediate value to the caller anticipating the return structure.
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?
Despite the absence of an output schema, the description enumerates specific return fields (name, address, phone, status), providing sufficient mental model for a simple read-only resource accessor. For a zero-parameter tool, this level of detail is adequate, though it could benefit from indicating the scope (e.g., 'current authenticated business').
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?
Input schema has zero parameters, triggering the baseline score of 4. With no parameters to document, no additional semantic annotation is required in the description text.
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?
Clear verb ('Get') and resource ('business profile details') with specific field enumeration (name, address, phone, status). However, it fails to distinguish from the similar sibling 'pex_get_business_my_profile' or clarify if this retrieves the authenticated business entity versus a specific target.
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?
Provides no guidance on when to invoke this tool versus siblings like 'pex_get_business_settings', 'pex_get_business_my_profile', or 'pex_get_account_details'. No prerequisites or contextual conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business settings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. While 'Get' implies read-only behavior, the description lacks specifics on return format, data freshness, authentication requirements, or what setting categories are included (preferences, limits, configurations?).
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?
At three words, the description is concise but inadequately front-loaded for the crowded sibling context. It wastes no words, but fails to prioritize differentiation from pex_get_business_profile and other business getters in the available space.
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?
Without an output schema and surrounded by 10+ pex_get_business_* siblings, the description inadequately scopes what data is returned. It does not clarify whether settings include preferences, limits, or configurations, nor how they differ from 'profile' or 'billing' data.
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 contains zero parameters, triggering the baseline score of 4 per rubric guidelines. No parameter documentation is required.
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 'Get business settings' is tautological, merely restating the tool name (pex_get_business_settings) without defining what constitutes 'business settings' or differentiating from siblings like pex_get_business_profile, pex_get_business_billing, or pex_get_business_balance.
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?
No usage guidance provided. With numerous sibling tools fetching business-related data (profile, balance, billing, admins, etc.), the description fails to specify when this tool is preferred over alternatives or what specific use case it serves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific business tag by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tag ID |
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. While 'Get' implies a read-only operation, the description does not explicitly confirm safety, disclose error handling (e.g., what happens if the ID is not found), describe the return structure, or mention any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly six words with no filler. It is front-loaded with the verb 'Get' and immediately conveys the resource and lookup key. Every word earns its place.
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 required parameter, simple lookup) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks information about the return structure or error cases that would be helpful for 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?
The input schema has 100% description coverage ('Tag ID' for the id parameter). The description adds 'by ID' which reinforces the parameter's purpose, but does not add significant semantic detail beyond what the schema already provides. Baseline score applies.
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 action ('Get'), resource ('business tag'), and lookup method ('by ID'), which implicitly distinguishes it from the sibling tool 'pex_get_business_tags' (plural). However, it does not explicitly name the sibling or clarify when to use the singular vs. plural variant.
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 'pex_get_business_tags'. It does not mention prerequisite conditions (e.g., having a specific tag ID) or that the plural version should be used for listing all tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all business tags
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden but provides minimal behavioral context. It does not clarify if this is read-only (though implied), what fields are returned, pagination behavior, or whether results are cached/filterable.
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 single phrase contains no wasted words and is appropriately sized for a simple endpoint, though brevity crosses into under-specification. Front-loading is irrelevant given the minimal length.
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?
While the tool is simple (zero parameters), the absence of an output schema means the description should compensate by describing the return structure or tag semantics. It meets minimum viability but leaves significant gaps for an unannotated 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?
Input schema contains zero parameters, establishing baseline 4. The description correctly implies no filtering parameters are accepted by stating 'Get all', aligning with the empty 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 states the basic action ('Get') and resource ('business tags'), but does little more than restate the tool name. It marginally distinguishes from sibling 'pex_get_business_tag' (singular) by specifying 'all', yet fails to explain what business tags are or how they differ from 'pex_get_transaction_tags'.
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?
No guidance provided on when to use this versus the singular 'pex_get_business_tag' or 'pex_get_transaction_tags'. No mention of pagination limits, caching considerations, or prerequisites for accessing business-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific business transaction by ID
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Get' implying read-only access, but does not disclose error behavior (e.g., 404 scenarios), authentication requirements, or what data structure is returned.
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?
Single sentence of appropriate length with no redundant words. However, given zero annotations and no output schema, the extreme brevity leaves significant gaps rather than being efficiently informative.
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?
Without annotations or output schema, the description should explain what constitutes a 'business transaction' versus cardholder transactions, or what fields are included. It does not compensate for missing structured metadata.
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 has 100% coverage with 'transactionId' described as 'Transaction ID'. Description adds 'by ID' which reinforces the parameter purpose but adds no additional semantic detail (syntax examples, ID format) beyond 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?
Clear verb ('Get') and resource ('business transaction') with scope ('specific...by ID'), but fails to distinguish from sibling tool 'pex_get_business_transactions' (plural/list version) or clarify relationship to 'pex_get_transaction_detail'.
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?
No guidance provided on when to use this single-record lookup versus the plural 'pex_get_business_transactions', nor when to prefer this over 'pex_get_cardholder_transaction' for cardholder-specific records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated business transactions with optional date, amount, and category filters
| Name | Required | Description | Default |
|---|---|---|---|
| minDate | No | Filter transactions on or after this date-time (eastern time, ISO 8601) | |
| maxDate | No | Filter transactions on or before this date-time (eastern time, ISO 8601) | |
| onDate | No | Filter transactions on this exact date (eastern time, ISO 8601). Cannot be combined with minDate/maxDate | |
| minAmount | No | Filter transactions with amount >= this value | |
| maxAmount | No | Filter transactions with amount <= this value | |
| equalsAmount | No | Filter transactions with amount exactly equal to this value. Cannot be combined with minAmount/maxAmount | |
| page | No | Page number (1-based, default: 1, max: 2147483647) | |
| pageSize | No | Results per page (default: 100, range: 1–1000) | |
| sortBy | No | Sort results by property. Valid values: TransactionTime (default), Amount, Description | |
| orderBy | No | Sort direction. Valid values: Asc, Desc (default) | |
| onlyCategoryIds | No | Only include transactions in these category IDs | |
| notCategoryIds | No | Exclude transactions in these category IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It correctly identifies the 'paginated' nature of the response, which hints at pagination behavior. However, it lacks details on read-only safety, rate limits, or the specific return format beyond implying a transaction list.
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 single sentence is efficiently front-loaded with the core action ('Get paginated business transactions') followed by filter categories. Every word earns its place and there is no redundancy. However, the extreme brevity leaves gaps given the 12-parameter 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 rich schema (100% coverage) but lack of output schema or annotations, the description is minimally adequate. It identifies the resource type and pagination, but omits sibling differentiation, parameter interaction rules (e.g., mutual exclusivity of date filters), and response structure hints that would help an agent invoke the tool correctly.
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%, establishing a baseline score of 3. The description adds minimal semantic value beyond the schema, but usefully categorizes filters into 'date, amount, and category' groups that map to the parameter structure. It does not add syntax details or validation rule explanations.
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 action (Get), resource (business transactions), and scope (paginated with filters). It distinguishes 'business transactions' from sibling 'cardholder transactions' by naming, though it could better differentiate from the singular variant 'pex_get_business_transaction'.
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 mentions pagination and filter availability but provides no explicit guidance on when to use this tool versus siblings like 'pex_get_business_transaction' (singular) or 'pex_get_cardholder_transactions'. It does not indicate that all parameters are optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific callback subscription by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Subscription ID |
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. 'Get' implies a read-only operation, but the description lacks details on return format, error handling (e.g., 404 if ID not found), idempotency, or side effects.
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 a single, efficient sentence with no wasted words. It is front-loaded with the action verb and immediately conveys the operation's intent and required input pattern.
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 simple retrieval tool with one required parameter and no output schema, the description provides the minimal viable context for tool selection. However, it lacks explanation of what a 'callback subscription' represents or what data is returned, which gaps the description should address given the absence of annotations or 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?
With 100% schema description coverage (the 'id' parameter is documented as 'Subscription ID'), the schema performs the heavy lifting. The description mentions 'by ID' which aligns with the parameter, but adds no additional semantic context about acceptable ID formats or constraints beyond 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 provides a specific verb (Get), resource (callback subscription), and scope (specific by ID). The phrase 'by ID' implicitly distinguishes this from the sibling tool 'pex_list_callback_subscriptions', though it could more explicitly clarify the singleton vs. collection distinction.
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 offers no guidance on when to use this tool versus alternatives like 'pex_list_callback_subscriptions'. It does not indicate prerequisites (e.g., needing an ID from a previous list call) or when lookup by ID is preferred over listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available callback subscription types
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description fails to disclose if this is cached, the structure of returned types, or any rate limiting. 'Get' implies read-only but lacks explicit safety guarantees or idempotency notes.
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?
Extremely concise at 5 words. Front-loaded with verb, no filler. Appropriately sized for a simple enumeration endpoint.
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?
Sufficient for basic invocation but omits how returned 'types' relate to subscription creation workflow. Given rich sibling ecosystem (pex_get_callback_subscription, pex_list_callback_subscriptions), description should clarify this retrieves the catalog of event types available for subscription.
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?
Zero parameters present per schema (100% coverage of empty set). Baseline score applies as there are no parameters requiring semantic elaboration.
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?
Clear verb 'Get' and resource 'callback subscription types'. Distinct from sibling pex_get_callback_subscription (which retrieves a specific subscription instance) by focusing on the available type definitions/categories rather than active subscriptions.
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?
No guidance on when to invoke this versus pex_list_callback_subscriptions or pex_get_callback_subscription. Does not indicate this is typically called before creating a subscription to see available event types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get card profile/details by card account ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Card account ID |
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 fails to indicate whether this is a real-time query, what permissions are required, what happens when the ID is not found, or whether the data contains sensitive PII. The implicit safety of a 'Get' operation is not sufficient for a financial domain 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 single sentence is front-loaded with the action verb and contains no redundant words. However, given the complexity of the surrounding tool ecosystem (80+ siblings), the extreme brevity may be a liability rather than a virtue, as it sacrifices disambiguating context.
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 tool with 100% schema coverage on a single parameter and no output schema, the description meets the minimum threshold. However, it does not compensate for the lack of annotations or output schema by describing return value structure, nor does it help navigate the dense sibling namespace to prevent incorrect tool selection.
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% (the 'id' parameter is fully described as 'Card account ID'). Per the rubric, this sets a baseline of 3. The description adds minimal semantic value beyond what the schema already provides, simply repeating that the parameter is a card account ID without adding format constraints, examples, or validation logic.
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 identifies the verb (Get), resource (card profile/details), and key identifier (card account ID). However, it does not effectively distinguish from numerous sibling card-specific endpoints like pex_get_card_spend_rules or pex_get_card_orders, which could confuse selection in a crowded tool ecosystem.
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?
No guidance is provided on when to use this general card retrieval endpoint versus the many specific card-related siblings (e.g., spend rules, orders, limits). There are no explicit prerequisites, exclusion criteria, or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get advanced spending rules for a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Card account ID |
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, yet only implies read-only access through the verb 'Get'. It fails to describe what constitutes an 'advanced' rule, what data structure is returned, or whether the card must be active/valid.
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 single sentence is efficient and front-loaded with the action and target resource. However, given the crowded namespace with 60+ similar siblings, extreme brevity becomes a liability rather than virtue.
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?
Inadequate for an API surface with numerous similar spending-rule tools and no output schema. The description should clarify the relationship between card-specific advanced rules and ruleset-level configurations, and hint at return value structure.
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 coverage (the 'id' parameter is fully documented as 'Card account ID'), the schema does the heavy lifting. The description adds no parameter-specific context (e.g., expected ID format, where to obtain this ID), warranting the baseline score of 3.
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 states a clear verb ('Get') and resource ('advanced spending rules'), but adds minimal semantic value beyond the tool name itself. It fails to differentiate from similar siblings like 'pex_get_card_spend_rules' (basic vs advanced) or ruleset-related endpoints, leaving ambiguity about which tool to select.
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?
No guidance provided on when to use this tool versus alternatives such as 'pex_get_card_spend_rules' or the various 'ruleset' endpoints. No prerequisites, filtering guidance, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated cardholder declines. Optionally filter by cardholder account ID.
| Name | Required | Description | Default |
|---|---|---|---|
| cardholderAccountId | No | Optional cardholder account ID to scope results | |
| minDate | No | Filter transactions on or after this date-time (eastern time, ISO 8601) | |
| maxDate | No | Filter transactions on or before this date-time (eastern time, ISO 8601) | |
| onDate | No | Filter transactions on this exact date (eastern time, ISO 8601). Cannot be combined with minDate/maxDate | |
| minAmount | No | Filter transactions with amount >= this value | |
| maxAmount | No | Filter transactions with amount <= this value | |
| equalsAmount | No | Filter transactions with amount exactly equal to this value. Cannot be combined with minAmount/maxAmount | |
| page | No | Page number (1-based, default: 1, max: 2147483647) | |
| pageSize | No | Results per page (default: 100, range: 1–1000) | |
| sortBy | No | Sort results by property. Valid values: TransactionTime (default), Amount, Description | |
| orderBy | No | Sort direction. Valid values: Asc, Desc (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but offers minimal behavioral context beyond 'paginated.' It does not describe the return value structure (critical given no output schema), side effects, rate limits, or parameter interaction rules like the mutual exclusivity of onDate vs minDate/maxDate that exists in the schema descriptions.
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 two-sentence structure is appropriately front-loaded with the core action. While compact, the second sentence ('Optionally filter by cardholder account ID') merely restates information available in the schema parameter description, slightly reducing its earned value.
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 an 11-parameter filtering tool with complex constraints and no output schema, the description is insufficient. It omits explanation of return structures, key parameter constraints (mutually exclusive groups), and how 'declines' differ from the multiple sibling transaction endpoints available on this server.
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%, providing baseline documentation for all 11 parameters. The description adds minimal value by noting the pagination aspect and the optional cardholder filter, but does not illuminate semantic relationships between parameters (e.g., mutually exclusive date filters) or provide usage context beyond what the schema already covers.
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 provides a clear verb ('Get') and resource ('cardholder declines') with scope ('paginated'), satisfying basic clarity requirements. However, it fails to distinguish from sibling transaction tools like 'pex_get_cardholder_transactions' by clarifying that 'declines' specifically refers to failed/declined authorization attempts versus successful 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?
No explicit when/when-not guidance or alternative recommendations are provided. The description mentions only the cardholderAccountId filter, ignoring the other ten filtering parameters (dates, amounts, pagination controls) and their intended use cases, leaving the agent without guidance on when to apply specific filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get network transactions for a specific cardholder within a date range
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Cardholder account ID | |
| startDate | Yes | Start date (ISO 8601) | |
| endDate | Yes | End date (ISO 8601) |
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 fails to explain what 'network transactions' specifically means (vs internal/other types), return format, pagination limits, or data freshness—critical gaps for a financial data 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. However, the brevity comes at the cost of omitting important contextual information, making it efficient in structure but underweight in content.
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?
Despite having well-documented input parameters, the description lacks output schema guidance (what fields are returned?) and fails to define domain-specific terms ('network transactions') in a complex API with many similar transaction-related siblings.
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 baseline is 3. The description maps the 'id' parameter to 'specific cardholder' and the date parameters to 'date range,' adding minimal semantic context but no additional syntax guidance beyond the ISO 8601 specification 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 provides a clear verb (Get), resource (network transactions), and scope (specific cardholder within date range). It distinguishes from siblings like 'pex_get_network_transactions' (general) and 'pex_get_cardholder_transactions' (all types) by combining both 'cardholder' and 'network' qualifiers.
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?
No guidance provided on when to use this over similar sibling tools like 'pex_get_cardholder_transactions' or what distinguishes 'network' transactions from other transaction types. No mention of prerequisites like valid date ranges or account permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token provisioning mode for a specific cardholder
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Cardholder account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Beyond implying a read operation via 'Get', it discloses nothing about return format, possible enum values for provisioning modes, error behaviors, or idempotency. Insufficient for a technical financial domain 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 a single, efficient sentence (7 words) front-loaded with the action verb 'Get'. While appropriately sized for a simple single-parameter tool, it borders on overly terse given the technical domain ('token provisioning mode' warrants brief elaboration). No structural waste 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?
For a basic getter with one parameter and no output schema, the description minimally suffices by identifying the resource. However, it fails to explain what 'token provisioning mode' means (possible values, format) or how it relates to sibling tool 'pex_get_token_provisioning_mode', leaving agents without crucial context to interpret results.
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 coverage is 100% (parameter 'id' fully documented as 'Cardholder account ID'), establishing baseline 3. Description adds no supplementary semantics, validation rules, or examples beyond the schema, but doesn't need to given complete schema documentation.
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?
Clear verb-resource combination ('Get token provisioning mode') and specific scope ('for a specific cardholder'). Distinguishes from business/card-level siblings, though ambiguity remains regarding the distinction from 'pex_get_token_provisioning_mode'.
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?
No guidance provided on when to use versus alternatives (particularly 'pex_get_token_provisioning_mode'), prerequisites, or error conditions. Agents must infer applicability solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific cardholder purchase by transaction ID, optionally scoped to a cardholder
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Transaction ID | |
| cardholderAccountId | No | Optional cardholder account ID to scope the lookup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden of behavioral disclosure. It mentions 'optionally scoped' hinting at parameter behavior, but lacks information on return format, error handling (e.g., invalid transaction ID), data sensitivity, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence (11 words) that front-loads the core action and scope. No redundancy or filler content.
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?
Adequate for a simple two-parameter retrieval tool, but lacks description of return values or error conditions (no output schema exists to compensate). Missing completeness given no annotations and absent 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 coverage is 100% with clear parameter descriptions ('Transaction ID', 'Optional cardholder account ID to scope the lookup'). Tool description echoes these semantics ('by transaction ID', 'optionally scoped') but adds no additional syntax guidance or examples. Baseline 3 appropriate 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?
Clear verb ('Get') and resource ('cardholder purchase'), and specifies the lookup key ('by transaction ID'). Distinguishes somewhat from sibling 'pex_get_cardholder_purchases' (plural) by using 'specific,' but does not clarify semantic difference from 'pex_get_cardholder_transaction' siblings.
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?
No explicit guidance on when to use this vs. alternatives. Does not indicate when the optional cardholderAccountId should be provided or what distinguishes a 'purchase' from a 'transaction' in the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated cardholder purchases. Optionally filter by cardholder account ID and approval status.
| Name | Required | Description | Default |
|---|---|---|---|
| cardholderAccountId | No | Optional cardholder account ID to scope results | |
| approval | No | Filter by approval/review status. Valid values: NotReviewed, Ignored, Approved, Rejected, NoReceipt | |
| minDate | No | Filter transactions on or after this date-time (eastern time, ISO 8601) | |
| maxDate | No | Filter transactions on or before this date-time (eastern time, ISO 8601) | |
| onDate | No | Filter transactions on this exact date (eastern time, ISO 8601). Cannot be combined with minDate/maxDate | |
| minAmount | No | Filter transactions with amount >= this value | |
| maxAmount | No | Filter transactions with amount <= this value | |
| equalsAmount | No | Filter transactions with amount exactly equal to this value. Cannot be combined with minAmount/maxAmount | |
| page | No | Page number (1-based, default: 1, max: 2147483647) | |
| pageSize | No | Results per page (default: 100, range: 1–1000) | |
| sortBy | No | Sort results by property. Valid values: TransactionTime (default), Amount, Description | |
| orderBy | No | Sort direction. Valid values: Asc, Desc (default) |
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 'paginated' which hints at response behavior, but lacks disclosure of return format, rate limits, authentication requirements, or warnings about the unconstrained query (all 12 parameters are optional, which could return massive datasets).
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?
Two efficient sentences with no wasted words. However, given the tool's complexity (12 parameters including date ranges, amounts, and sorting), the description is arguably too brief and front-loads only the basic concept rather than the most important filtering constraints.
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?
Inadequate for a tool with 12 filtering parameters and no output schema. The description omits date filtering capabilities, amount ranges, sorting options, and pagination parameters entirely, leaving significant gaps despite the rich 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?
With 100% schema description coverage, the baseline is 3. The description mentions only 2 of the 12 parameters (cardholderAccountId and approval), confirming their optional nature, but does not add semantic value for the date ranges, amount filters, or pagination controls already well-documented 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?
Describes a specific action (Get) on a clear resource (cardholder purchases) and mentions pagination behavior. However, it fails to distinguish from similar sibling tools like 'pex_get_cardholder_transactions' or the singular 'pex_get_cardholder_purchase', leaving ambiguity about when to use this specific endpoint.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., the singular purchase getter or transaction endpoints). No mention of prerequisites, required context, or exclusion criteria for using the filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific cardholder transaction by transaction ID, optionally scoped to a cardholder
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Transaction ID | |
| cardholderAccountId | No | Optional cardholder account ID to scope the lookup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Get' implies read-only behavior, the description fails to disclose error handling (e.g., 404 if transaction not found), return data structure, authentication requirements, or idempotency guarantees expected for a retrieval 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?
Single sentence, appropriately front-loaded with action verb. Every word earns its place—'specific' distinguishes from list operations, 'optionally scoped' addresses the optional parameter. No redundancy or waste.
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 simple 2-parameter lookup tool with 100% schema coverage and no nested objects, the description adequately conveys basic functionality. However, given the lack of output schema and annotations, the absence of return value description or error behavior leaves minor gaps in contextual 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?
Schema description coverage is 100% (both parameters well-documented in schema), so baseline score applies. The description maps closely to the schema ('by transaction ID' = transactionId, 'optionally scoped' = cardholderAccountId) but adds no additional semantic depth, validation constraints, or format details beyond the structured definitions.
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?
Clear specific verb 'Get' and resource 'cardholder transaction'. The phrase 'by transaction ID' effectively distinguishes this from the sibling list operation 'pex_get_cardholder_transactions' (plural). However, it does not clarify when to use this versus 'pex_get_transaction_detail' or other similar transaction retrieval 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?
Provides implicit guidance through 'optionally scoped to a cardholder', indicating when the optional cardholderAccountId parameter should be used. However, lacks explicit guidance on when to prefer this tool over siblings like pex_get_cardholder_transactions (list vs. specific) or pex_get_cardholder_purchases (transaction types).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated cardholder transactions. Optionally filter by cardholder account ID.
| Name | Required | Description | Default |
|---|---|---|---|
| cardholderAccountId | No | Optional cardholder account ID to scope results | |
| minDate | No | Filter transactions on or after this date-time (eastern time, ISO 8601) | |
| maxDate | No | Filter transactions on or before this date-time (eastern time, ISO 8601) | |
| onDate | No | Filter transactions on this exact date (eastern time, ISO 8601). Cannot be combined with minDate/maxDate | |
| minAmount | No | Filter transactions with amount >= this value | |
| maxAmount | No | Filter transactions with amount <= this value | |
| equalsAmount | No | Filter transactions with amount exactly equal to this value. Cannot be combined with minAmount/maxAmount | |
| page | No | Page number (1-based, default: 1, max: 2147483647) | |
| pageSize | No | Results per page (default: 100, range: 1–1000) | |
| sortBy | No | Sort results by property. Valid values: TransactionTime (default), Amount, Description | |
| orderBy | No | Sort direction. Valid values: Asc, Desc (default) | |
| onlyCategoryIds | No | Only include transactions in these category IDs | |
| notCategoryIds | No | Exclude transactions in these category IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses 'paginated' behavior which is critical for agent expectation management. No annotations provided, so description carries full burden of behavioral disclosure. However, it omits mention of the complex mutual exclusivity constraints between date filters (onDate vs minDate/maxDate) and amount filters that exist in the schema.
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?
Two sentences, front-loaded with action verb. No redundant filler. However, given the tool's complexity (13 parameters with intricate filtering logic), the description errs on the side of under-specificity rather than wastefulness.
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 13 parameters with rich filtering capabilities (dates, amounts, categories, sorting) and no output schema, the description is insufficient. It fails to signal the availability of date-range filtering, amount filtering, or category exclusion capabilities that distinguish this from simpler transaction retrieval 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?
Input schema has 100% description coverage with detailed parameter semantics (ISO 8601 formats, eastern time, ranges, mutual exclusivity). Description mentions one parameter ('cardholder account ID') but adds no additional semantic detail beyond what the schema already provides. Baseline 3 appropriate 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?
States specific verb ('Get') and resource ('paginated cardholder transactions'). Mentions 'Optionally filter' which distinguishes from potential mandatory-filter siblings. However, it fails to explicitly differentiate from siblings 'pex_get_cardholder_transaction' (singular) and 'pex_get_all_cardholder_transactions' which presumably have different scoping behaviors.
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?
Implies optional filtering via 'Optionally filter by cardholder account ID' but provides no explicit guidance on when to choose this paginated endpoint versus 'pex_get_all_cardholder_transactions' or the singular 'pex_get_cardholder_transaction'. No 'when-not' or alternative recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get remaining card load limit for a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Card account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full behavioral burden. While 'Get' implies read-only operation, the description lacks disclosure of error handling (what happens if card ID not found?), rate limits, or return value structure.
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?
Single front-loaded sentence of nine words with zero redundancy. Appropriately sized for a simple getter, though minimalism leaves gaps in behavioral disclosure.
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?
Minimally adequate for a single-parameter getter. Explains what is retrieved but omits contextual clarification of what 'load limit' means compared to spending limits or credit lines available from 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 has 100% description coverage with 'Card account ID' clearly documented. Description mentions 'for a specific card' which conceptually maps to the ID requirement, but adds no syntax details or format guidance beyond the schema baseline.
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 uses specific verb 'Get' with clear resource 'remaining card load limit' and scope 'for a specific card'. It distinguishes from sibling tool pex_get_account_remaining_limits by specifying 'card' level vs 'account' level limits.
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?
Provides no guidance on when to use this tool versus siblings like pex_get_card (which gets general card details) or pex_get_account_remaining_limits. No mention of prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific card order by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Card order ID |
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 fails to mention what happens if the ID is not found (404 vs null), authentication requirements, or whether the operation is read-only (though implied by 'Get').
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 a single, efficient sentence with no wasted words. It is appropriately front-loaded with the action and target resource.
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 simple single-parameter retrieval tool with complete schema coverage, the description is sufficient despite lacking an output schema. The combination of description and schema adequately specifies the input contract.
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 'id' parameter fully documented as 'Card order ID'. The description adds minimal semantic value beyond the schema baseline, merely noting the operation is 'by ID'.
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 provides a specific verb ('Get') and resource ('card order') with scope ('specific...by ID'). However, it does not explicitly distinguish from sibling tool 'pex_get_card_orders' (plural), which likely returns a list versus this single-item lookup.
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?
No guidance provided on when to use this tool versus alternatives like 'pex_get_card_orders' (for listing multiple orders) or 'pex_get_vendor_card_order' (for vendor-specific orders). The agent must infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get card orders within an optional date range
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date (ISO 8601) | |
| endDate | No | End date (ISO 8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden but only states the read operation 'Get' without confirming safety, side effects, pagination behavior, or response format. The mention of 'optional' adds minimal behavioral context about parameter 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?
Eight words, zero waste. Front-loaded with verb, immediately conveys resource and scope. Appropriate length for a simple two-parameter retrieval tool.
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?
Adequate for the low complexity (two optional string parameters, flat schema), but lacks essential information about return values, pagination limits, or the distinction between this and the singular sibling tool given no output schema exists.
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 has 100% coverage (ISO 8601 descriptions), establishing baseline 3. Description adds value by framing the two parameters as 'an optional date range', clarifying they function together as optional filters rather than independent required fields.
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?
Clear verb 'Get' with resource 'card orders' and scope 'within an optional date range'. However, it fails to distinguish from sibling tool 'pex_get_card_order' (singular), which likely retrieves a specific order by ID rather than listing multiple orders.
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?
No guidance provided on when to use this bulk retrieval tool versus the singular 'pex_get_card_order' alternative. No mention of prerequisites, typical use cases, or filtering behavior when dates are omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scheduled funding rules for a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Card account ID |
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 but fails to expand beyond restating the operation name. It does not clarify what 'scheduled funding rules' specifically entails (e.g., auto-funding schedules, recurrence patterns), disclose return value structure, or indicate caching/rate limit behaviors despite the 'Get' verb implying read-only access.
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 eight-word sentence is efficiently front-loaded with the action verb and contains no redundant filler. However, given the complete absence of annotations and output schema, the description may be inappropriately terse as it leaves significant behavioral and response context unstated.
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 simple single-parameter read operation with 100% schema coverage, the description minimally suffices to identify the resource, but leaves gaps regarding response structure and business logic. Without annotations or output schema to reference, the description should ideally explain what constitutes 'scheduled funding rules' to be fully complete.
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 achieves 100% description coverage, fully documenting the single 'id' parameter as 'Card account ID'. Since the schema provides complete semantic information, the description baseline is 3; it neither adds complementary parameter context nor omits necessary details that the schema fails to cover.
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 provides a specific verb ('Get') and resource ('scheduled funding rules') with clear scope ('for a specific card'), accurately describing the operation. However, it does not explicitly differentiate from functionally similar sibling tools like `pex_get_card_spend_rules` or `pex_get_card`, relying instead on the agent to parse the resource name subtleties.
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 offers no guidance on when to select this tool versus alternatives such as `pex_get_card_advanced_spend_rules` or `pex_get_card`, nor does it mention prerequisites like obtaining the card ID beforehand. It lacks contextual signals an agent would need to determine if funding rules versus spend rules are appropriate for the user request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get spending rules for a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Card account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. While 'Get' implies read-only, the description doesn't confirm safety characteristics, error behaviors (e.g., invalid card ID), or whether rules include pending vs active configurations.
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?
Single 6-word sentence with no redundancy. Efficiently front-loaded with action verb. Appropriately sized for simple operation, though sibling complexity warrants slightly more detail.
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?
Minimum viable for a 1-parameter read operation. Critical gap: no differentiation from 'advanced' spending rules siblings. Lacks behavioral details expected when no annotations or output schema exists.
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 has 100% coverage with 'id' documented as 'Card account ID'. Description adds no parameter guidance, but with high schema coverage, baseline 3 is appropriate per scoring rules.
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?
Clear verb+resource+scope: 'Get spending rules for a specific card'. However, it fails to distinguish from sibling tool 'pex_get_card_advanced_spend_rules', leaving ambiguity about when to use the basic vs advanced version.
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?
No guidance provided on when to use this tool versus alternatives like 'pex_get_card_advanced_spend_rules' or 'pex_get_spending_ruleset'. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get credit line information for the business
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses nothing beyond the operation name. It fails to specify what 'credit line information' entails (limit, available credit, utilized amount, terms), nor does it mention permissions, caching behavior, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient but borders on under-specification given the crowded sibling namespace and lack of annotations/output schema. It earns its place functionally but leaves significant context gaps.
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 30+ similar 'get' siblings, no annotations, no output schema, and zero parameters, the description is insufficient. It fails to clarify what credit line data is returned or how it differs from account/balance endpoints, leaving agents to guess selection criteria.
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?
Input schema contains zero parameters (empty object), establishing a baseline of 4. The description appropriately does not invent parameters, though it could have explained why no business_id or filters are needed (e.g., if it uses authenticated 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?
States a clear verb (Get) and resource (credit line information) with scope (for the business). However, it does not explicitly differentiate from numerous siblings like `pex_get_business_balance` or `pex_get_account_details` that likely return overlapping financial data.
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?
Provides no guidance on when to select this tool versus the many other `pex_get_*` siblings (e.g., business_balance, account_details). No prerequisites, filtering guidance, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of the current authentication token
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. States it retrieves 'details' but does not specify what details (scopes, expiry, user_id, etc.) or whether operation is idempotent/cached. Fails to explain 'current' means the token active in this request 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?
Single sentence with no redundancy. Appropriately brief given zero parameters, though could accommodate one additional clarifying clause about output content without violating conciseness.
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?
Minimum viable for a simple read operation. Lacks output schema and annotations; description compensates by identifying the target resource but omits return value structure or content hints that would aid interpretation of results.
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?
Zero parameters exist (empty schema), which per guidelines establishes a baseline of 4. Description correctly omits parameter discussion as there are none to document.
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?
Uses specific verb 'Get' and resource 'current authentication token'. The 'current' qualifier implicitly distinguishes this from sibling tools like 'pex_list_tokens' and 'pex_get_auth_tokens' (which likely return multiple/all tokens), though explicit contrast is not stated.
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?
Provides no guidance on when to use this versus alternatives like 'pex_get_auth_tokens' or 'pex_list_tokens'. No mention of use cases such as token introspection or validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cardholders belonging to a specific group. Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group ID | |
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (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 of behavioral disclosure. It successfully notes that 'Results are paginated,' which is critical for list operations. However, it omits other behavioral traits like rate limits, required permissions, or whether the operation is read-only (implied but not confirmed).
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 consists of two efficient sentences with zero waste. The first front-loads the core purpose while the second provides essential behavioral context (pagination). Every word earns its place with no 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?
Given this is a simple read operation with 100% schema coverage and no nested objects, the description is suitably complete. It appropriately mentions pagination behavior. It lacks an output schema, but for a standard list retrieval, the description sufficiently conveys the operation's scope without needing to enumerate return fields.
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 coverage is 100%, so the baseline is 3. The description mentions 'paginated,' which provides semantic context for the 'page' and 'pageSize' parameters, but otherwise adds no additional format guidance or validation rules beyond what the schema already provides.
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 (Get), resource (cardholders), and scope constraint (belonging to a specific group). It distinguishes this from general cardholder retrieval tools by specifying the group-based filtering, though it could explicitly reference sibling tools like pex_list_groups to clarify the relationship between groups and cardholders.
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 'belonging to a specific group,' suggesting a group ID is required, but provides no explicit guidance on when to use this versus other cardholder-related tools (e.g., pex_get_cardholder_transactions) or prerequisites like obtaining the group ID first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get allocations for a specific invoice
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Invoice ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure but offers almostnone. It implies a read operation via 'Get' but does not confirm safety, idempotency, rate limits, or what happens if the invoice ID does not exist.
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 single sentence is compact with no redundant words. However, extreme brevity results in underspecification rather than elegant conciseness—critical domain context is omitted to keep it short.
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?
With no output schema and no annotations, the description fails to clarify the return structure, content scope of 'allocations,' or distinction from similar financial operations (payments, bills). Inadequate for disambiguating this specialized financial resource.
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 coverage is 100% with 'Invoice ID' describing the 'id' parameter. The description mentions 'specific invoice' which loosely corresponds to the parameter, but adds no semantic detail about valid ID formats, ranges, or how to obtain one. Baseline 3 appropriate given schema completeness.
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 states the basic action (Get) and resource (allocations) but 'allocations' is a vague domain term without clarification. It maps closely to the tool name (pex_get_invoice_allocations → 'Get allocations'), offering minimal elaboration on what allocations represent in this financial context or how they differ from invoice payments.
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?
No guidance provided on when to use this versus siblings like pex_get_invoice_payments or pex_get_invoices. No mention of prerequisites (e.g., obtaining the invoice ID from another call) or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get payments for a specific invoice
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Invoice ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. While 'Get' implies a read-only operation, the description does not confirm idempotency, safety guarantees, rate limits, or what data structure is returned (array vs object).
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?
Extremely concise at 7 words with no redundant phrases. The sentence is front-loaded with the action and object, containing zero 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?
Despite a simple single-parameter input, the tool exists in a complex domain with 60+ siblings including similar payment/invoice tools. The description inadequately situates this tool within that ecosystem and omits behavioral details necessary for a tool without annotations or output schema 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?
The input schema has 100% description coverage ('Invoice ID'), so the schema adequately documents the single parameter. The description adds no supplemental information about the ID format or semantics, meeting the baseline score for high-coverage schemas.
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?
States a clear verb ('Get') and resource ('payments for a specific invoice'), identifying the operation precisely. However, it fails to distinguish from siblings like 'pex_get_payments' or 'pex_get_bill_payments', leaving ambiguity about when to use this specific endpoint versus generic payment getters.
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?
Provides no guidance on when to use this tool versus alternatives such as 'pex_get_invoices' or 'pex_get_payments'. No mention of prerequisites (e.g., needing an invoice ID from elsewhere) or conditions where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business invoices starting from a given date
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | Start date (ISO 8601 date-time) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden, yet fails to mention pagination behavior, data freshness, maximum date ranges, or whether results include paid/unpaid invoices. 'Get' implies read-only but doesn't confirm non-destructive behavior.
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?
Single sentence of 7 words is efficiently front-loaded with no redundancy. However, brevity leaves significant gaps given the absence of annotations and output schema—slightly too minimal for the context.
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?
Despite simple single-parameter input, the tool lacks both annotations and output schema. Description omits expected return structure, pagination controls, and relationship to 'pex_get_invoice_allocations' or 'pex_get_invoice_payments' siblings, leaving operational context incomplete.
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 has 100% coverage describing 'startDate' as ISO 8601 date-time. Description mentions 'starting from a given date' which confirms the parameter's filtering role but adds no additional semantic detail (e.g., timezone handling, inclusive/exclusive boundaries) beyond 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?
Clear verb 'Get' and specific resource 'business invoices', with temporal scope 'starting from a given date' distinguishing it from general billing tools. However, does not explicitly differentiate from siblings like 'pex_get_bill' or 'pex_get_business_billing' which may overlap in domain.
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?
Implies date-filtered retrieval with 'starting from a given date' but provides no explicit guidance on when to use versus other financial retrieval tools, nor prerequisites like date format constraints or maximum ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get issued tokens for a specific cardholder
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Cardholder account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Get' implies read-only access, it lacks disclosure on idempotency, token sensitivity, pagination behavior, or error conditions (e.g., if cardholder has no tokens).
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?
Extremely brief (7 words) with no filler. Front-loaded with action and target. However, brevity sacrifices necessary contextual detail for this complex domain.
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?
Inadequate for complexity. No output schema exists, yet description doesn't explain return structure, token format, or how results differ from 'pex_list_tokens' or other siblings in this 50+ tool set.
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 has 100% coverage with 'Cardholder account ID' describing the 'id' parameter. Description adds no parameter-specific context, meeting baseline for high-coverage schemas.
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?
Clear verb ('Get') and resource ('issued tokens') with scope ('for a specific cardholder'). However, it fails to distinguish from siblings like 'pex_get_auth_tokens', 'pex_get_current_token', or 'pex_list_tokens', leaving ambiguity about the specific token type retrieved.
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?
No guidance provided on when to use this versus alternative token-related endpoints (e.g., auth tokens vs issued tokens) or prerequisites for the cardholder ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Merchant Category Code (MCC) categories. Filter by predefined and/or custom categories.
| Name | Required | Description | Default |
|---|---|---|---|
| includePredefined | No | Include predefined categories | |
| includeCustom | No | Include custom categories |
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. While 'Get' implies a read-only operation, the description fails to disclose what data structure is returned, whether results are paginated, or any rate limiting. It only mentions the filtering behavior without explaining the behavioral implications of the boolean flags.
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 consists of exactly two sentences with zero wasted words. The first sentence declares the purpose immediately, and the second clarifies the filtering mechanism. Appropriately sized for the tool's simplicity.
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 low complexity (2 optional boolean parameters, no required fields, no nested objects) and lack of output schema, the description is minimally adequate. However, it lacks mention of the return format or structure, which would be helpful context given no output schema exists.
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 schema already documents both boolean parameters ('Include predefined categories', 'Include custom categories'). The description reframes these as 'Filter by...' which adds minimal semantic context, meeting the baseline expectation 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 uses a specific verb ('Get') and identifies the exact resource ('Merchant Category Code (MCC) categories'). The parenthetical 'MCC' helps distinguish this from sibling tools like pex_get_business_tags. However, it doesn't explicitly differentiate when to use this versus other categorization 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 mentions filtering capability ('Filter by predefined and/or custom categories'), which implies usage context, but provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get network transactions for the business within a date range. Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | Start date (ISO 8601) | |
| endDate | Yes | End date (ISO 8601) | |
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (default: 50, max: 100) |
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 successfully discloses pagination behavior ('Results are paginated'), which helps the agent understand iteration is required. However, it omits other behavioral traits like whether this requires specific permissions, rate limits, or if the data is real-time vs cached.
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 consists of two efficient sentences with zero redundancy. The first sentence front-loads the core action and resource, while the second adds the critical behavioral detail (pagination). Every word earns its place.
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 simple flat schema (4 basic parameters) and lack of output schema, the description adequately covers the operational contract. However, given the dense sibling namespace of transaction-related tools, the description should clarify what 'network transactions' specifically denotes in this domain to prevent incorrect selection.
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 schema fully documents all four parameters (date formats, page logic, defaults). The description mentions 'date range' and 'paginated', which align with but do not extend beyond the schema's semantic definitions. Baseline 3 is appropriate for high-coverage schemas where the description adds minimal extra 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 verb (Get), resource (network transactions), scope (for the business), and filter (date range). It partially distinguishes from siblings like 'pex_get_cardholder_network_transactions' by specifying 'for the business', but fails to clarify what distinguishes 'network transactions' from 'business transactions' or other transaction types in the 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 provides no guidance on when to use this tool versus alternatives like 'pex_get_business_transactions' or 'pex_get_cardholder_network_transactions'. The mention of pagination describes behavior, not usage criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get partner details for the current business
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Get' implies read-only, the description doesn't confirm idempotency, disclose what specific 'partner' data entails, mention authentication requirements, or explain the return structure (especially important given no output schema exists).
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 a single, efficient sentence with the verb front-loaded. Every word earns its place; there is no redundancy or waste given the simplicity of the tool (zero parameters).
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 zero-parameter read operation, the description is minimally adequate, but lacks important context: without an output schema or annotations, it fails to define what constitutes a 'partner' (integration partner? referral partner?) or what details are returned, leaving significant ambiguity 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?
Input schema has zero parameters, establishing a baseline of 4. The description adds context by specifying 'for the current business,' which explains the implicit scope/identifier (why no explicit parameters are needed), providing value beyond the empty 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 uses a specific verb ('Get') and resource ('partner details') plus scope ('for the current business'), making the purpose clear. It distinguishes implicitly from siblings by targeting 'partner' rather than 'business', 'account', or 'vendor', though it doesn't explicitly clarify when to prefer this over similar business info 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 provides no guidance on when to use this tool versus alternatives like pex_get_business_profile or pex_get_vendor. There are no prerequisites, conditions, or explicit alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific payment request by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Payment request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States only the basic retrieval action without disclosing error handling (e.g., invalid ID), idempotency, data sensitivity, or side effects. Minimal 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?
Extremely concise at 7 words. Front-loaded with verb. No wasted words, though 'specific' adds minimal value. Appropriately brief for simple lookup but arguably too terse given lack of annotations.
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?
Minimally adequate for a single-parameter retrieval tool with full schema coverage. Lacks domain context (what constitutes a payment request?), error scenarios, and differentiation from similar endpoints in the large sibling set.
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 coverage is 100% with 'id' parameter fully documented as 'Payment request ID'. Description mentions 'by ID' reinforcing the parameter's purpose but adds no additional syntax, format constraints, or examples beyond 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?
Uses specific verb 'Get' and resource 'payment request' with scope 'by ID'. However, fails to distinguish from sibling 'pex_get_bill_payment_request' or clarify relationship to 'pex_get_payments' (list vs single item).
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?
Provides no guidance on when to use this tool versus alternatives like 'pex_get_payments' (likely a list endpoint) or 'pex_get_bill_payment_request'. No prerequisites or conditions specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated list of business payments with optional filtering by status, dates, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| size | No | Results per page | |
| paymentStatuses | No | Filter by payment status. Valid values: Draft, Pending, Closed, Exception, InProgress | |
| paymentStatusTriggers | No | Filter by status trigger. Valid values: New, OutboundAchCreationError, Settling, OutBoundAchCheckStatusError, AwaitingOutboundCompletion, Settled, Returned, Cancelled, InProgress, VirtualCardCreated, VirtualCardEnsureSpendingRuleset, VirtualCardDeliveryCreated, VirtualCardDetailsRequestCreated, VirtualCardCreationError, VirtualCardEnsureSpendingRulesetError, VirtualCardDeliveryCreationError, VirtualCardDetailsRequestCreationError | |
| outboundAchCreationStartDate | No | ACH creation start date (ISO 8601) | |
| outboundAchCreationEndDate | No | ACH creation end date (ISO 8601) | |
| expectedPaymentStartDate | No | Expected payment start date (ISO 8601) | |
| expectedPaymentEndDate | No | Expected payment end date (ISO 8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It successfully discloses pagination behavior (critical for implementation), but omits read-only safety confirmation, rate limits, return format details, or max page size constraints that would help an agent invoke this correctly.
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?
Single sentence, front-loaded with action. Efficient length, though 'etc.' wastes space and represents missed opportunity to specify the ACH/date filtering capabilities evident in the parameter names.
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?
Adequate for a list endpoint with well-documented parameters (100% schema coverage), but minimal given zero annotations and no output schema. Lacks domain context (e.g., that these are ACH/business disbursements) that would help distinguish from invoice or bill payments in the sibling list.
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 detailed parameter definitions (including valid status values), establishing baseline of 3. Description acknowledges 'status, dates' filtering exists but adds no additional semantic context, syntax clarification, or usage examples beyond what the schema already provides.
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?
Clear verb 'Get' and resource 'business payments' with mention of pagination. However, 'etc.' is vague and it doesn't clarify how 'business payments' differ from siblings like pex_get_payment_request, pex_get_bill_payments, or pex_get_payment_transfer, which could confuse tool selection.
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?
No guidance on when to use this versus sibling payment tools (e.g., payment requests vs actual payments). No mention of prerequisites or filtering strategies. The agent must infer usage from parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific payment transfer by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transfer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, but there is no disclosure of error handling (e.g., not found behavior), idempotency, or rate limiting considerations.
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?
Extremely concise single sentence with front-loaded action verb. No redundant or filler text; every word serves the purpose statement.
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 single-parameter, simple retrieval pattern and 100% schema coverage, the description is minimally viable. However, without an output schema or annotations, and given the crowded sibling namespace of similar payment tools, it lacks necessary disambiguation 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% with the 'id' parameter documented as 'Transfer ID'. The description mentions 'by ID' but adds no additional semantic detail (format constraints, valid ranges) beyond the schema itself, warranting the baseline score.
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 (Get) and resource (payment transfer) and specifies retrieval 'by ID', implying single-record lookup. However, it does not explicitly differentiate from siblings like pex_get_payments or pex_get_payment_request.
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?
Provides no guidance on when to use this tool versus alternatives (pex_get_payments for lists, pex_get_payment_request for requests) or prerequisites like required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific spending ruleset by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ruleset ID |
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. While 'Get' implies a read-only operation, the description omits any details about what a spending ruleset contains, potential error conditions (e.g., invalid ID), or whether caching is involved.
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 extremely terse at seven words, front-loaded with the action and resource. While efficient, its extreme brevity contributes to the lack of contextual guidance and behavioral transparency.
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 retrieval tool with full schema coverage, the description is minimally viable. However, given the lack of output schema, missing annotations, and unexplained relationship to the 'advanced' sibling tool, it falls short of being fully complete.
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 coverage is 100% with the 'id' parameter clearly described as 'Ruleset ID' in the schema. The description mentions 'by ID', aligning with the parameter, but adds no additional semantic depth (e.g., whether this is a PEX system ID or external identifier) beyond what the schema already provides.
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 provides a specific verb ('Get') and resource ('spending ruleset') and specifies the lookup method ('by ID'). However, it fails to distinguish from siblings like 'pex_get_advanced_spending_ruleset' or 'pex_list_spending_rulesets', leaving ambiguity about which tool to use.
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?
No guidance is provided on when to use this tool versus alternatives such as the 'advanced' variant or the list operation. There are no prerequisites, conditions, or explicit exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cards assigned to a specific spending ruleset. Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ruleset ID | |
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior ('Results are paginated'), which is critical for implementation. However, with no annotations provided, description fails to disclose error behaviors (404 vs empty array), rate limits, authentication requirements, or return value structure.
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?
Two sentences, zero waste. First sentence establishes purpose; second sentence discloses pagination constraint. Appropriately front-loaded and sized for a straightforward retrieval operation.
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?
Adequate for a paginated list tool with complete input schema coverage, but gaps remain: no output schema is provided, yet description does not indicate what card data is returned (IDs, full objects, etc.) or error handling patterns.
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 coverage is 100% with clear descriptions for id, page, and pageSize. Description mentions 'specific spending ruleset' which loosely contextualizes the id parameter, but adds no additional semantic value regarding pagination parameters beyond schema defaults.
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?
States specific action (Get) and resource (cards assigned to spending ruleset) clearly. Distinguishes from pex_get_spending_ruleset (which gets the ruleset itself) via 'cards assigned to' phrasing, but does not clarify when to use this vs pex_get_advanced_spending_ruleset_cards sibling.
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?
Provides no guidance on when to select this tool versus alternatives like pex_get_advanced_spending_ruleset_cards or pex_get_card_spend_rules. Does not mention prerequisites like needing a valid ruleset ID from pex_list_spending_rulesets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the business token provisioning mode
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 fails to disclose what values the 'provisioning mode' can return, what format the response takes, or any authentication requirements inherent to business-level operations.
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 a single, efficient sentence with no wasted words. However, given the lack of annotations and output schema, extreme brevity works against completeness.
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?
While the description identifies the resource, it is incomplete regarding return values and behavioral constraints due to the absence of an output schema. It meets minimum viability but leaves significant documentation 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?
The input schema contains zero parameters, which establishes a baseline of 4. With no parameters to describe, there is no additional semantic information required beyond 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 (Get) and resource (business token provisioning mode). It implicitly distinguishes from the sibling 'pex_get_cardholder_provisioning_mode' by specifying 'business', though it does not explicitly clarify the distinction.
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?
No guidance provided on when to use this versus the sibling 'pex_get_cardholder_provisioning_mode' or other token-related tools. The agent must infer usage from the naming convention alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific attachment for a transaction
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Transaction ID | |
| attachmentId | Yes | Attachment ID | |
| attachmentLinkType | No | How to return the attachment. Valid values: LinkUrl (default), Full, Thumbnail, Preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet the description fails to disclose what the tool returns (binary content vs URL vs metadata) or explain the behavioral differences between attachmentLinkType options (LinkUrl vs Full vs Thumbnail).
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?
Extremely efficient at 7 words with verb-first structure. However, given the behavioral complexity (multiple link types) and sibling ambiguity, it may be overly terse rather than appropriately 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?
Incomplete for a tool with distinct retrieval modes (LinkUrl/Full/Thumbnail) and a plural counterpart sibling. Missing explanation of return values (critical given no output schema) and differentiation from list operations.
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 coverage, the baseline is 3. The description 'Get a specific attachment' loosely implies the attachmentId parameter's purpose but adds no semantic detail beyond the schema's existing 'Transaction ID' and 'Attachment ID' 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?
Clear verb ('Get') and resource ('attachment') with scope ('for a transaction'). However, it does not explicitly distinguish from sibling tool 'pex_get_transaction_attachments' (plural) which likely retrieves all attachments versus this single-retrieval tool.
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?
Provides no guidance on when to use this tool versus 'pex_get_transaction_attachments' or other transaction-related tools. No mention of prerequisites or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all attachments for a transaction
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Transaction ID |
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 via 'Get' but does not confirm safety, idempotency, or what happens when the transaction has no attachments (empty vs error). It also fails to describe the return format or structure.
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 a single, efficient sentence that is front-loaded with the verb. However, given the complete absence of annotations and output schema, the extreme brevity (6 words) leaves critical gaps in documentation; it is under-specified rather than appropriately 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?
For a tool with no output schema and no annotations, the description should explain what is returned (list of attachments, their format, metadata) and behavioral traits. It provides neither, leaving the agent unaware of the response structure or error behaviors.
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 coverage is 100% (transactionId is documented as 'Transaction ID'), establishing a baseline of 3. The description mentions 'for a transaction' which contextually links the parameter to the operation, but adds no details about ID format, source, or constraints beyond what the schema already provides.
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 uses a specific verb ('Get') and resource ('attachments') and includes the scope modifier 'all', which implicitly distinguishes this from the sibling tool 'pex_get_transaction_attachment' (singular). However, it does not make this distinction explicit or clarify when to use which tool.
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, prerequisites (e.g., needing a valid transaction ID from prior calls), or error conditions. It omits any mention of the singular 'pex_get_transaction_attachment' sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details for a specific transaction by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transaction ID |
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 yet provides none. It does not indicate what specific details are returned, error behavior (e.g., 404 for invalid IDs), rate limits, or whether this includes metadata/tags that might require separate 'pex_get_transaction_tags' calls.
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 single 9-word sentence is efficient and front-loaded with the action and resource. However, given the lack of annotations and output schema, the description is arguably underspecified rather than optimally concise—it earns points for structure but could have accommodated more detail without becoming verbose.
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?
Adequate for a single-parameter lookup tool with no output schema provided, but insufficient given the API complexity (60+ sibling tools). The description should clarify the singular-vs-plural distinction and hint at the data scope to prevent confusion with 'pex_get_cardholder_transaction' or 'pex_get_business_transaction'.
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 coverage is 100% (the single 'id' parameter is documented as 'Transaction ID'), establishing a baseline of 3. The description mentions 'by ID' which aligns with the schema but adds no additional semantic value such as ID format constraints, where to obtain valid IDs, or validation rules.
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 (Get), resource (transaction details), and scope (specific transaction by ID). However, it fails to distinguish from the sibling tool 'pex_get_transaction_details' (plural), which likely returns multiple records versus this singular retrieval.
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?
No guidance provided on when to use this specific endpoint versus alternatives like 'pex_get_transaction_details', 'pex_get_cardholder_transaction', or 'pex_get_business_transaction'. The existence of 60+ sibling tools makes this absence particularly problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details for the business within a date range. Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | Start date (ISO 8601) | |
| endDate | Yes | End date (ISO 8601) | |
| includePendings | No | Include pending transactions | |
| includeDeclines | No | Include declined transactions | |
| page | No | Page number (1-based, default: 1) | |
| pageSize | No | Results per page (default: 50, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It successfully discloses pagination behavior ('Results are paginated'), which is critical for implementation. However, lacks other behavioral context like auth requirements, rate limits, or what specific details are returned in the response.
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?
Two efficient sentences with zero waste. Front-loaded with purpose, followed by critical behavioral note on pagination. Appropriate length for the tool 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?
With no output schema provided, description adequately covers the input parameters (via schema) and pagination behavior. However, lacks description of return structure or transaction detail content. Given 6 parameters and complex sibling landscape, completion is adequate but has clear 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 all parameters are fully documented in the schema (ISO 8601 formats, boolean flags, pagination defaults). Description implies date range usage but adds no semantic detail beyond schema; baseline 3 warranted per rubric for high-coverage schemas.
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?
States clear verb ('Get') and resource ('transaction details') and scope ('for the business within a date range'). Mention of 'business' helps distinguish from cardholder-specific siblings, but does not clarify distinction vs similar tools like pex_get_business_transactions or pex_get_transaction_detail (singular).
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?
No guidance on when to select this tool over siblings (e.g., business vs cardholder scope, detailed vs summary view). No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tags for a specific transaction
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but reveals minimal behavioral traits beyond the read-only implication of 'Get'. It lacks critical details such as the return format (array vs object), error handling for invalid transaction IDs, and behavior when no tags exist.
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 a taut five-word phrase containing no wasted words. However, given the absence of annotations and output schema, this brevity is inappropriate for the contextual complexity, leaving critical information gaps that conciseness cannot excuse.
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?
The description fails to compensate for the missing output schema by describing expected return values or tag structure. Given the extensive sibling toolset with overlapping transaction concerns, it lacks necessary scoping to clarify when this specific endpoint is preferred over general transaction detail retrieval.
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 coverage is 100%, meaning the 'transactionId' parameter is already documented as 'Transaction ID' in the schema itself. The description mentions 'specific transaction' which aligns with the parameter but adds no semantic details about ID format, constraints, or examples beyond the schema definition.
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 provides a clear verb ('Get') and resource ('tags for a specific transaction'), identifying the basic operation. However, it fails to differentiate from siblings like 'pex_get_transaction_detail' or clarify what 'tags' specifically entail in this domain versus other transaction metadata.
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 offers no guidance on when to select this tool over related alternatives such as 'pex_get_transaction_detail' or 'pex_get_cardholder_transactions'. It omits prerequisites, permissions, or conditions that would trigger the need for tag retrieval specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific vendor by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Vendor ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description adds minimal behavioral context beyond the implied read-only operation. Does not disclose return format, error behavior on invalid IDs, or whether the operation is idempotent.
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?
Extremely concise at six words with no redundancy. The single sentence is front-loaded and immediately conveys the operation, though brevity comes at the cost of behavioral context.
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?
Adequate for a simplesingle-parameter retrieval operation, but lacks error handling documentation and output expectations that would compensate for the missing annotations and 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 coverage is 100% with the 'id' parameter already documented as 'Vendor ID'. The description reinforces this with 'by ID' but adds no additional semantic value regarding format, constraints, or valid ID ranges.
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?
Clear verb ('Get'), resource ('vendor'), and scope ('by ID'). Implicitly distinguishes from 'pex_list_vendors' by specifying 'specific' and 'ID', though it lacks explicit cross-referencing to the sibling list 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?
No guidance on when to use this single-record retrieval versus the 'pex_list_vendors' sibling. No mention of error conditions (e.g., vendor not found) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vendor card order details by order ID
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | Vendor card order ID |
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. While 'Get' implies a read-only operation, the description does not confirm safety, disclose what happens if the orderId is invalid, or describe the return payload structure.
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 compressed into 9 words with no redundancy. Every word serves a purpose. However, it is minimal to the point of omitting useful context that would help distinguish this from similar endpoints, preventing a score of 5.
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 required parameter, no nested objects, no output schema expected), the description is minimally adequate. However, with no annotations and no output schema, it should ideally clarify what constitutes a 'vendor card order' or what details are returned to ensure the agent selects it appropriately.
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 coverage is 100%, with the orderId parameter already documented as 'Vendor card order ID'. The description echoes this with 'by order ID' but adds no additional semantic context (e.g., format constraints, whether this is a PEX-internal ID or external reference). With complete schema coverage, this meets the baseline expectation.
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 uses a clear verb ('Get') and identifies the resource ('vendor card order details') and scope ('by order ID'). It implicitly distinguishes from siblings like 'pex_get_card_order' by including 'vendor' and from 'pex_get_vendor' by including 'card order', though it doesn't explain the domain relationship between these entities.
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 siblings like 'pex_get_card_order' or 'pex_get_vendor'. It does not state prerequisites (e.g., needing the orderId from a previous search) or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all advanced spending rulesets for the business
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description carries minimal burden. States retrieval action but omits pagination behavior, result set limits, or whether inactive rulesets are included—critical gaps for a 'list all' 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?
Single sentence, front-loaded with action verb, no redundant phrases. However, brevity is excessive given lack of behavioral and sibling-differentiation context needed for this tool ecosystem.
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?
Adequate for a parameter-less list operation, but incomplete given the rich sibling context (14+ ruleset-related tools). Lacks output format details and distinguishing guidance necessary for correct tool selection.
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?
Input schema contains zero properties. Per grading rules, 0 params warrants baseline score of 4.
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?
Uses specific verb 'Get' and resource 'advanced spending rulesets'. Distinguishes from card-level operations via 'for the business' and from singular retrieval via 'all', though does not clarify what distinguishes 'advanced' from standard rulesets.
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?
Provides no guidance on when to use this versus sibling tools like 'pex_list_spending_rulesets' (non-advanced) or 'pex_get_advanced_spending_ruleset' (singular retrieval), nor prerequisites or filtering limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all callback subscriptions for the business, optionally filtered by type
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Callback type filter. Valid values: Card, Cardorder, CardOrderVirtual, CardTokenCreated, AuthRealtime, PinRealtime, DeclineRealtime, ReversalRealtime, SettlementPostedRealtime |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Get' implying read-only access but does not confirm safety, disclose return format, pagination behavior, or rate limiting context for this collection endpoint.
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?
Single sentence (12 words) with front-loaded verb. No redundancy, but arguably too compressed given lack of output schema and annotations—could accommodate one additional sentence distinguishing from singular sibling.
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?
Adequate for a single-parameter list operation with full schema coverage, but misses opportunity to clarify relationship with 'pex_get_callback_subscription' in the crowded sibling namespace. No output schema documented.
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 coverage is 100% (baseline 3). Description adds value by confirming the optional nature of filtering with 'optionally filtered by type', aligning with the parameter's non-required status in 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?
Uses specific verb 'Get' with clear resource 'callback subscriptions' and scope 'for the business'. Mentions optional filtering. Distinguishes from 'pex_get_callback_types' (different resource) but fails to clarify distinction from singular 'pex_get_callback_subscription' sibling.
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?
Provides no explicit guidance on when to use this versus the singular 'pex_get_callback_subscription' or what constitutes a valid use case. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cardholder groups for the business
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but only states the basic read operation. It lacks mention of pagination behavior, authorization requirements, rate limits, or what constitutes a 'cardholder group' in this 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 single sentence is appropriately front-loaded and contains no redundancy. However, given the lack of annotations and output schema, the extreme brevity leaves functional gaps that an additional sentence or two could address without harming conciseness.
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?
Adequate for a zero-parameter list operation but minimal. Without an output schema, the description should ideally characterize the return structure (e.g., array of group objects) or indicate this is a business-level enumeration operation.
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?
Input schema contains zero parameters; per rubric, this establishes a baseline score of 4. The description implies no parameter requirements by stating 'Get all', which is consistent with the empty 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 provides a specific verb ('Get') and resource ('cardholder groups') with business scope. It implicitly distinguishes from the sibling 'pex_get_group_cardholders' by targeting the groups themselves rather than cardholders within a group, though it could explicitly clarify this distinction.
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?
No guidance provided on when to use this versus 'pex_get_group_cardholders' or other list operations. Given the extensive sibling toolset (60+ tools), explicit usage context or prerequisites would be necessary for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all spending rulesets for the business
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Get' implies read-only, the description fails to disclose pagination behavior, expected response size, rate limiting, or whether this returns active rulesets only or all historical records. It also does not clarify the relationship between 'spending rulesets' and 'advanced spending rulesets'.
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 extremely concise at seven words with no redundancy. However, this brevity becomes a liability given the lack of annotations and output schema; the description is front-loaded but sacrifices necessary contextual detail for the sake of brevity.
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 absence of annotations, the lack of an output schema, and the existence of multiple sibling tools with similar purposes (advanced variants, singular gets), the description is incomplete. It should clarify the distinction between standard and advanced spending rulesets and indicate whether pagination is handled automatically or via tokens.
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 contains zero parameters, warranting the baseline score of 4 per the evaluation rubric. The description's phrasing 'Get all' correctly signals that no filtering parameters are required, which aligns with the empty 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 uses a clear verb ('Get') and identifies the resource ('spending rulesets') and scope ('for the business'), implying a complete unfiltered list. However, it does not distinguish this from the sibling 'pex_list_advanced_spending_rulesets' or explain what constitutes a 'standard' vs 'advanced' ruleset.
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 the singular 'pex_get_spending_ruleset' or the 'advanced' variant siblings. It does not mention any prerequisites, filtering limitations, or pagination behavior that would help an agent decide between this and other list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all tokens for the authenticated user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only indicates read behavior via 'Get'. Missing: pagination behavior, data sensitivity of tokens, rate limits, whether tokens are masked, or specific return structure (no output schema provided).
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?
Single sentence, front-loaded with verb, zero redundancy. Every word necessary: subject (tokens), scope (all), context (authenticated user).
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?
Minimally viable for a zero-parameter list operation. Agent understands what is retrieved, but description lacks behavioral details expected when annotations are absent. Sibling ambiguity leaves gaps in contextual understanding.
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?
Zero parameters exist, so baseline 4 applies per rubric. Description confirms operation requires no input filters (implied by 'all tokens'), consistent with empty 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?
States specific verb (Get), resource (tokens), and scope constraint (for the authenticated user). Clear about what it retrieves, though it could clarify what 'tokens' refers to in this domain (e.g., API tokens vs card tokens) given ambiguous sibling names like `pex_get_auth_tokens`.
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?
Provides no guidance on when to use this versus the three sibling token tools (`pex_get_auth_tokens`, `pex_get_current_token`, `pex_get_issued_tokens`). Does not indicate if this returns a superset or different type of token data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated list of vendors with optional filtering by cardholder, status, and status trigger
| Name | Required | Description | Default |
|---|---|---|---|
| cardholderAcctId | No | Filter by cardholder account ID | |
| vendorStatuses | No | Filter by vendor status. Valid values: Draft, Pending, Onboarded, Closed | |
| vendorStatusTriggers | No | Filter by vendor status trigger. Valid values: New, Submitted, Active, Inactive, Rejected, Offboarded | |
| pageIndex | No | Page index (1-based, range: 1–1000000) | |
| pageSize | No | Results per page (range: 1–1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full disclosure burden. It successfully conveys the paginated nature of the response and implies read-only safety via 'Get', but omits details about default pagination behavior, rate limits, authentication requirements, or what occurs when no filters are applied.
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?
Single 12-word sentence that is perfectly front-loaded with the core action. Every word earns its place; no redundancy or filler.
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 straightforward list operation with simple scalar parameters and no output schema, the description adequately covers the core functionality (listing, pagination, filtering). However, it lacks mention of default page sizes or the all-optional parameter nature that would complete the invocation 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%, establishing a baseline of 3. The description adds minimal semantic value by confirming filters are 'optional' and grouping them conceptually, but does not expand on parameter formats, relationships, or validation rules beyond what the schema already documents.
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?
States specific verb 'Get' and resource 'vendors', and includes 'paginated list' which distinguishes this from sibling pex_get_vendor (singular). However, it does not explicitly name the sibling or clarify when to use the list vs. single-get 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?
Describes what filtering capabilities exist (cardholder, status, status trigger) but provides no explicit guidance on when to use this tool versus pex_get_vendor or other alternatives, nor any prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bills with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| createdDateFrom | No | Created date from (ISO 8601) | |
| createdDateTo | No | Created date to (ISO 8601) | |
| dueDateFrom | No | Due date from (ISO 8601) | |
| dueDateTo | No | Due date to (ISO 8601) | |
| vendorId | No | Filter by vendor ID | |
| page | No | Page number | |
| pageSize | No | Page size |
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 but reveals almost nothing. It does not mention that results are paginated (despite having page/pageSize parameters), what the return format contains, or whether searches without filters return all records.
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 extremely brief (4 words) and front-loaded, but arguably underspecified for a tool with 7 parameters including date ranges and pagination controls. While not wasteful, it lacks necessary elaboration 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 7-parameter complexity and lack of output schema, the description is incomplete. It fails to mention pagination behavior, result set characteristics, or the distinction between this search functionality and the singular 'get' alternative.
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 baseline score is 3. The phrase 'optional filters' loosely references the filtering nature of the parameters but adds no semantic depth beyond the schema's already explicit field descriptions (e.g., 'Created date from').
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 provides a clear verb ('Search') and resource ('bills'), establishing the core function. However, it fails to distinguish from the sibling tool 'pex_get_bill' (which presumably retrieves a specific bill by ID), leaving ambiguity about when to use search versus direct retrieval.
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?
No guidance is provided on when to use this tool versus alternatives like 'pex_get_bill' or 'pex_get_bill_payments'. There are no preconditions, prerequisites, or explicit exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.2pex_get_account_balancepex_get_account_detailspex_get_account_remaining_limitspex_get_advanced_account_detailspex_get_advanced_spending_rulesetpex_get_advanced_spending_ruleset_cardspex_get_all_account_detailspex_get_all_cardholder_transactionspex_get_auth_tokenspex_get_billpex_get_bill_payment_requestpex_get_bill_paymentspex_get_business_adminpex_get_business_adminspex_get_business_balancepex_get_business_bank_accountpex_get_business_billingpex_get_business_linkedpex_get_business_my_profilepex_get_business_one_time_transferpex_get_business_profilepex_get_business_settingspex_get_business_tagpex_get_business_tagspex_get_business_transactionpex_get_business_transactionspex_get_callback_subscriptionpex_get_callback_typespex_get_cardpex_get_card_advanced_spend_rulespex_get_card_load_limit_remainingpex_get_card_orderpex_get_card_orderspex_get_card_scheduled_funding_rulespex_get_card_spend_rulespex_get_cardholder_declinespex_get_cardholder_network_transactionspex_get_cardholder_provisioning_modepex_get_cardholder_purchasepex_get_cardholder_purchasespex_get_cardholder_transactionpex_get_cardholder_transactionspex_get_credit_linespex_get_current_tokenpex_get_group_cardholderspex_get_invoice_allocationspex_get_invoice_paymentspex_get_invoicespex_get_issued_tokenspex_get_mcc_categoriespex_get_network_transactionspex_get_partnerpex_get_payment_requestpex_get_payment_transferpex_get_paymentspex_get_spending_rulesetpex_get_spending_ruleset_cardspex_get_token_provisioning_modepex_get_transaction_attachmentpex_get_transaction_attachmentspex_get_transaction_detailpex_get_transaction_detailspex_get_transaction_tagspex_get_vendorpex_get_vendor_card_orderpex_list_advanced_spending_rulesetspex_list_callback_subscriptionspex_list_groupspex_list_spending_rulesetspex_list_tokenspex_list_vendorspex_search_billsScored across 72 tools
The tools are mostly distinct, but there is notable overlap in areas like cardholder transactions (e.g., pex_get_cardholder_transactions, pex_get_all_cardholder_transactions, pex_get_cardholder_purchases) and business transactions (e.g., pex_get_business_transactions, pex_get_network_transactions, pex_get_transaction_details), which could cause confusion. Descriptions help differentiate some, but the sheer number of similar tools increases ambiguity.
Tool names follow a highly consistent verb_noun pattern, all starting with 'pex_get_' or 'pex_list_' and using snake_case throughout. This predictability makes it easy for agents to parse and understand the naming conventions across all 72 tools.
With 72 tools, the count is excessive for typical MCP server purposes, making it heavy and potentially overwhelming for agents. While the domain (financial/card management) is broad, the tool set could likely be consolidated or scoped more narrowly to improve usability.
The tool set provides extensive coverage for financial and card management operations, including account details, transactions, rules, billing, and administrative functions. Minor gaps might exist, such as update or delete operations for some resources, but agents can likely work around these given the comprehensive read-focused surface.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
