Loading ToolBench
Agentic discovery, onboarding, and payments from your machine. MCP server for managing authentication, balances, deposit addresses, payments (MPP/X402), AEP service enrollment, and inspection.
InFlow CLI exposes 23 tools with STDIO-only transport. Tool definitions are present with basic descriptions and some input schemas, but quality is inconsistent. Naming follows verb_noun convention mostly (list_, enroll, grant, inspect, pay, fetch, decode, subscribe). Descriptions exist but are often generic (10-50 chars); many lack context on WHEN to use tools or what distinguishes them. Input schemas are visible for most tools but parameter descriptions are minimal or absent. Output schemas are not documented. Error handling strategy is not evident from the code samples provided. Security concerns: tools like auth_login, mpp_pay, x402_pay handle sensitive operations (authentication, irreversible payments) but no confirmation/dry-run pattern is visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite IRREVERSIBLE operations existing. The codebase is well-structured (TypeScript, turbo monorepo, comprehensive test setup) but MCP-specific patterns are underutilized.
Enroll a service with AEP (Agent Enablement Protocol)
Fetch seller resource using AEP credentials
Grant service access to protected resources via AEP
Inspect AEP service requirements and capabilities
Revoke service access previously granted via AEP
Check service enrollment and access status via AEP
Authenticate user and obtain session credentials
Output schemas completely undocumented. No schema definitions found for tool return types across all 23 tools. LLMs cannot predict response structure or plan downstream tool calls.
No input schemas visible for tools lacking explicit parameter documentation: balances_list, deposit-addresses_list, auth_logout, mpp_supported have no parameter definitions in code samples.
Irreversible operations (mpp_pay, x402_pay) lack confirmation/dry-run patterns. These tools execute IRREVERSIBLE payments with no guard against agent mistakes. No visible error recovery guidance or permission gates.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Logout the authenticated user and clear session
Check authentication status and user information
List the authenticated user's balances
List the authenticated user's configured deposit addresses
Inspect payment requirements and capabilities of a URL (combined ODP, AEP, MPP, X402)
Cancel an MPP payment approval
Decode an MPP value (challenge or response)
Fetch seller resource after MPP payment transaction
Inspect MPP (Merchant Payment Protocol) payment challenges on a URL
Execute a payment via MPP (Merchant Payment Protocol)
Check status of an MPP payment transaction
Subscribe to MPP payment notifications
Get list of supported MPP payment methods
Fetch seller resource after X402 payment
Inspect X402 payment requirements on a URL
Execute a payment via X402 protocol
Tool annotations missing. IRREVERSIBLE and WRITE operations have no destructiveHint or idempotentHint annotations. READ_ONLY operations lack readOnlyHint. Current MCP spec (2026-07-28) expects these for risk classification.
Generic or minimal descriptions (under 50 chars) on 12+ tools. LLMs cannot determine WHEN to select each tool. E.g., 'Decode an MPP value' lacks context on what decoding enables; 'Get list of supported MPP payment methods' doesn't explain why the agent should call it first.
Parameter descriptions missing or generic on most tools. E.g., auth_login accepts 'interval', 'maxAttempts', 'timeout' with only brief labels; no guidance on valid ranges, defaults, or why an LLM should adjust them.
Generic tool name 'inspect' lacks distinction. Four separate inspect tools (inspect, mpp_inspect, x402_inspect, aep_inspect) serve different protocols but the base 'inspect' name is ambiguous. LLMs may conflate them.
No error handling guidance visible. Tools operating on external resources (aep_fetch, mpp_pay, x402_pay) offer no documentation of failure modes, retry eligibility, or recovery steps.
Authentication credentials (from auth_login) presumably stored server-side, but no documentation of how subsequent tools authenticate or validate sessions. LLM cannot reason about auth state.
No pagination or result-limiting documented. Tools like balances_list, deposit-addresses_list, mpp_supported have no visible limit, offset, or page parameters. Large result sets will blow context windows.