Loading ToolBench
Bridge server connecting Agent Communication Protocol (ACP) agents with Model Context Protocol (MCP) clients
This server exhibits mixed quality. Naming is generally clear with verb-first conventions (get_, discover_, execute_, list_, add_, provide_, cancel_), but descriptions are inconsistent, some are concise and actionable, others are vague or lack context for when to use them. Parameters have type definitions but many lack detailed descriptions beyond the bare noun. Schemas are present but incomplete; notably, return types are not documented in most tools, forcing LLMs to infer output structure. Error handling is absent from visible code, no guidance on recovery strategies, retryability classification, or actionable error messages. The server spans 16 tools with reasonable separation of concerns (discovery, messaging, orchestration, routing, interaction), but several tools combine multiple responsibilities (e.g., execute_agent_sync/async/stream could be unified with a mode parameter). The interactive agent pattern (start_interactive_agent + provide_user_input) is well-conceived but lacks timeout semantics and confirmation patterns for destructive operations.
Add a new routing rule to a strategy
Analyze the content types and structure of an ACP message
Cancel a pending interactive agent interaction
Convert ACP message format to MCP-compatible format
Discover all available ACP agents and register them as resources
Start an asynchronous ACP agent execution and return immediately with run ID
Execute an ACP agent with streaming output
Return types not documented. Tools like execute_agent_sync, execute_agent_stream, and convert_acp_message do not specify what structure they return (expected fields, data types, pagination). LLMs cannot plan downstream tool calls or extract results reliably.
Parameter descriptions are minimal. Many parameters (e.g., 'strategy' in smart_route_request, 'mode' in execute_agent_async) lack context on valid values, constraints, or format. The description should specify 'Routing strategy to use: default|custom|priority_match' with examples, not just 'Routing strategy to use (default: "default")'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Execute an ACP agent synchronously and wait for completion
Get detailed information about a specific ACP agent
Get the status of an asynchronous agent run
Get information about the ACP-MCP bridge server
List all pending interactive agents waiting for input
List all available routing strategies and their rules
Provide user input to resume a waiting interactive agent
Intelligently route a request to the best ACP agent
Start an interactive ACP agent that may require user input
Error handling missing. No visible code demonstrates how tools respond to failures (invalid agent_name, timeout, routing failure, network error). Tools should return typed error responses with recovery guidance (e.g., 'Agent not found. Call discover_acp_agents() to list available agents.').
Redundant execution tools. The server offers three variants of agent execution (sync, async, stream) with nearly identical signatures. This increases cognitive load for LLMs deciding between them. Consolidate into one execute_agent tool with an 'output_mode' enum (sync|async|stream) and optional session_id.
No confirmation pattern for destructive operations. Tools like add_routing_rule and cancel_pending_interaction modify state but lack dry-run or confirmation support. An agent could accidentally delete a critical routing strategy. Implement a confirm_before_execute pattern or require explicit 'confirm: true' parameter.
Missing pagination support. Tools returning collections (discover_acp_agents, list_routing_strategies, list_pending_interactions) do not document limit/offset/page parameters or total_count in responses. Large agent or routing lists could exhaust context windows.
Ambiguous parameter names. 'session_id' appears in multiple execute_* and interactive tools but is never defined. Is it a user session? A conversation thread? A request trace ID? Also, 'strategy' in smart_route_request and 'strategy_name' in add_routing_rule use different naming conventions for the same concept.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. LLMs cannot automatically infer which tools are safe to retry, which modify state, or which are read-only. This is a current MCP 2026-07-28 pattern that should be present.
Message bridge tools lack practical utility. convert_acp_message and analyze_message_content operate on raw JSON strings, but the tool descriptions and parameters do not clarify when an LLM should call them, what transformations they perform, or what the output looks like. These feel like internals exposed prematurely.