Loading ToolBench
Server monitoring agent with MCP and A2A protocol support, offering tool-based infrastructure inspection, diagnostics, deployment, and remote execution
Dozor is an A2A/MCP orchestration server with 7 tools. All tools have explicit definitions with names, descriptions, and input schemas visible in the source code (internal/a2a/client_tools.go, internal/mcpclient/tools.go, internal/skills/tools.go). Naming follows verb_noun patterns (list, discover, call). Descriptions are present and actionable (10 - 150 chars). However, there are significant gaps: (1) Most parameters lack descriptions, 'params' in mcp_call has only 'Tool parameters as JSON object', which is vague; (2) Output schemas are not documented, tools return strings with no structured schema defined; (3) No error handling guidance, tools return raw errors with no recovery hints; (4) No parameter validation rules (enum constraints, min/max), agents must guess valid values; (5) No tool annotations (readOnlyHint/destructiveHint) despite clear write risks (a2a_call, mcp_call are WRITE tools but unmarked). The server follows basic tool composition (each tool does one thing), but lacks the polish expected of production-grade systems. Overall structure is sound but descriptions, validation, and error guidance need hardening.
Send a message to a remote A2A agent and get a response
Discover capabilities of a remote A2A agent by fetching its agent card
List available remote A2A agents
Call a tool on a remote MCP server. Pass tool name and parameters as JSON.
Discover tools available on a remote MCP server
List configured remote MCP servers
Load the full instructions of a skill by name
mcp_call 'params' parameter is vague, description says 'Tool parameters as JSON object' but does not specify which fields are required, what structure is expected, or what constraints apply. LLM must guess valid JSON structure for arbitrary remote tools.
No output schemas documented for any tool. All tools return plain strings (e.g., 'Available remote agents:\n- agent1...') with no structured schema definition. LLM cannot plan downstream tool calls or extract typed fields reliably.
No error handling guidance. When tools fail (invalid agent_id, network error, missing server), code returns raw error strings with no recovery hints (e.g., 'No remote agents configured. agent_id is required.' is good, but mcp_call returns nothing). LLM cannot determine if error is retryable or fatal.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 59 | - | v1 |
No tool annotations. a2a_call and mcp_call are destructive (WRITE risk) but have no readOnlyHint/destructiveHint annotations. LLMs cannot distinguish safe discovery tools from potentially harmful action tools without reading descriptions carefully.
Parameter descriptions are missing or minimal. 'agent_id' in a2a_call is described but has no hints about valid formats, whether it accepts names or IDs, or what to do if the agent is not found. LLM must try multiple formats to discover the right one.
No pagination support documented. a2a_list_agents and mcp_list_servers may return many items, but tool definitions do not include limit, offset, or cursor parameters. If the list grows, result could blow context window.
mcp_call is a generic gateway tool that accepts arbitrary tool names and parameters. No validation of tool_name against known MCP server definitions, no hints about which tools exist on which servers, and no guidance on parameter format for remote tools. High risk of invalid calls.