Loading ToolBench
A connector agent that bridges A2A (Agent-to-Agent) protocol with MCP (Model Context Protocol), providing an intuitive interface for connecting to and using MCP tools through A2A.
This server exhibits critical quality gaps across definition structure, schema clarity, and error handling. While 6 tools are registered, the actual tool definitions are not directly visible in the provided code excerpt, only tool invocations and registration logic appear. Parameters are documented in the registry call but lack proper JSON Schema type declarations. Descriptions are present but generic and under 100 characters, failing to explain WHEN or WHY an agent should use each tool. No parameter-level descriptions visible in schemas. No error handling guidance documented. No output schema definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The tool chain is broken: register_mcp_server requires a 'server_id', but subsequent tools reference 'tool_id', there is no documented mapping or lookup mechanism between servers and tools.
Call an MCP tool and get the results back.
Get a list of all the MCP servers we have registered.
Get a list of all available MCP tools across all servers.
Register a new MCP server with our connector.
Kick a server off our registry.
Remove a tool from our available tools list.
Missing output schema documentation. No tool describes what it returns, what fields are present, or what structure downstream tools receive. LLMs cannot plan next steps without knowing return fields.
Parameter descriptions incomplete or absent. Input schema for register_mcp_server includes 'transport_type' with enum-like description but no formal enum constraint. Parameters lack actionable constraints: what is a valid 'server_id' format? What is a valid URL format for 'server_url'?
Broken tool composition chain. register_mcp_server saves a 'server_id', but call_mcp_tool and remove_mcp_tool operate on 'tool_id'. No documented mechanism explains how to map between server_id and tool_id, or how to discover available tool_ids. This forces agents to guess or requires undocumented lookup procedures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Destructive operations (remove_mcp_server, remove_mcp_tool) have no confirmation, dry-run, or rollback mechanism. An agent mistake permanently removes registered tools. No error guidance if removal fails.
No error handling guidance. When call_mcp_tool is invoked with an invalid tool_id, what does the agent see? How does it recover? Descriptions do not explain error conditions or recovery paths.
Tool descriptions are generic and under 100 characters. 'Register a new MCP server with our connector' does not explain WHEN an agent should use this vs. other registration patterns, WHAT happens on successful registration, or WHAT data structures are returned. Baseline for A+ tools: 194 chars average, 100% have actionable docstrings.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot determine which tools are safe to retry, which modify state, and which are read-only without explicit hints. call_mcp_tool may be non-idempotent depending on the downstream MCP tool, but this is not declared.
call_mcp_tool accepts 'input_data' as a string ('JSON or plain text'), forcing the agent to serialize structured data to a string and the tool to parse it back. This adds error surface and wastes tokens. Input should be a structured object with typed fields.
list_mcp_servers and list_mcp_tools have no pagination parameters (limit, offset, page_size) or documentation of result truncation. If the registry grows to hundreds of servers/tools, the agent receives unbounded output that may exceed context limits.