Loading ToolBench
Programmable spend limits and audit trails so AI agents can pay for things without risking the wallet. An MCP server.
Imprest defines 7 tools with clear, domain-specific names (request_payment, get_balance, get_audit_log) that follow verb_noun conventions. Descriptions are present and substantive (100-200 chars), explaining WHAT each tool does and WHEN to use it. Input schemas are visible and typed. However, several critical gaps reduce the score: (1) output schemas are not documented, callers cannot see what fields to expect from responses; (2) error handling descriptions are absent, tools do not explain what errors are possible or how to recover; (3) parameter descriptions lack format/constraint details (e.g., recipient is '0x… Ethereum address' but no validation guidance); (4) no pagination support documented for list_pending_approvals despite potential for large result sets; (5) tool annotations (readOnlyHint, destructiveHint) are missing, forcing LLMs to infer side effects from descriptions alone.
Retrieve the audit log of all payment attempts for the calling agent. Returns all recorded decisions (allow, deny, needs_approval) and their outcomes (executed, failed, rejected, skipped, settlement_unknown).
Get the agent's wallet balance in ETH and configured tokens (e.g. USDC). Returns balances and estimated gas budget.
Get the active spend policy for the calling agent. Returns per-transaction limits, daily/hourly budgets, approval thresholds, recipient allow/deny lists, and per-asset token limits.
List all payments awaiting human approval (decision=needs_approval, status=recorded). Only callable by admin users.
Request human approval for a payment that was marked needs_approval. Only callable by admin users (operators). Re-evaluates the payment against current policy limits before executing.
Output schemas not documented. Tools return structured data but callers cannot see field names, types, or nesting. LLMs must infer response structure from descriptions alone, risking misinterpretation.
Error handling guidance missing. Tool descriptions do not explain what errors are possible (e.g., insufficient balance, policy violation, invalid recipient) or how to recover. LLMs cannot self-correct on failure.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint tags. LLMs cannot distinguish safe (get_balance) from destructive (request_payment) tools without reading descriptions carefully.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Request a payment from the agent's wallet. The policy engine evaluates the request against spend limits, budget windows, and approval thresholds. Returns ALLOW (execute immediately), DENY (blocked), or NEEDS_APPROVAL (human approval required).
Resolve a pending approval by approving or rejecting it. Alias for request_approval; used by the operator CLI.
Parameter format constraints not explicit. 'recipient' is described as '0x… Ethereum address' but no regex pattern or validation rule is stated. LLMs may pass invalid addresses without guidance.
Pagination not documented for list_pending_approvals. No limit, offset, or cursor parameters visible. Large approval queues could blow context windows.