Loading ToolBench
MCP server implementation for Bill.com integration
18 tools with consistent Zod schema definitions and descriptions. Naming follows verb_noun pattern (approve_bill, create_vendor, archive_bill). Descriptions are present and contextual (avg ~120 chars), exceeding the 10-char minimum but below the 50-200 char LLM-optimized range for most tools. All tools have input schemas with type definitions. However, output schemas are not documented, responses are unstructured text or raw JSON stringification. Error handling returns text messages but lacks recovery guidance (e.g., 'Try search_vendors() first'). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite 7 DESTRUCTIVE tools. Parameter descriptions are present but sparse, many lack format/constraint details (e.g., date format YYYY-MM-DD is stated in some but not all date params). Duplicate tools (approve_bill vs approve_bill_v3, deny_bill_v3 without a deny_bill counterpart) signal composition issues.
Approve a bill that is pending approval in Bill.com.
Approve a bill using Bill.com v3 API. Uses the v3 approval workflow which: - Handles multi-step approvals correctly - Supports approval comments - Returns detailed status about the approval action Prefer this over approve_bill for better approval workflow support.
Approve a reimbursement request in Bill.com Spend & Expense using v3 API.
Archive (deactivate) a bill in Bill.com.
Archive a recurring bill in Bill.com. This stops future bill generation.
Archive (deactivate) a vendor in Bill.com. Archived vendors cannot be used for new bills but history is preserved.
Output schemas not documented. Responses are unstructured text or raw JSON.stringify(). LLMs cannot plan downstream tool calls or extract structured data reliably.
Duplicate/overlapping tools without clear differentiation. approve_bill vs approve_bill_v3 both approve bills; LLM must reason about which to use. No deny_bill counterpart to deny_bill_v3.
7 DESTRUCTIVE tools (archive_*) lack tool annotations (destructiveHint). No confirmation/dry-run pattern. Agents cannot distinguish safe from irreversible operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Archive a vendor credit in Bill.com.
Create a new bill in Bill.com.
Create a new bill payment in Bill.com to pay one or more bills.
Create a new budget in Bill.com Spend & Expense using v3 API.
Create a new recurring bill in Bill.com.
Create a new reimbursement request in Bill.com Spend & Expense using v3 API.
Create a new vendor in Bill.com.
Create a new vendor credit in Bill.com.
Create a new virtual card in Bill.com Spend & Expense using v3 API.
Deny a bill using Bill.com v3 API. Uses the v3 approval workflow which: - Handles denial in multi-step approval workflows - Supports denial comments (recommended for audit trail) - Returns detailed status about the denial action Prefer this over reject_bill for better approval workflow support.
Freeze a card in Bill.com Spend & Expense using v3 API.
Get the approval history for a specific bill or other object in Bill.com.
Error responses lack recovery guidance. Handlers return 'Error approving bill: {error}' without suggesting next steps (e.g., 'Try get_approval_history() to check current status').
Parameter descriptions lack format/constraint details. Date params state YYYY-MM-DD in some tools but not others. Enum descriptions (e.g., timePeriod '0'=None, '1'=Day) are sparse.