Loading ToolBench
Agent-to-Agent (A2A) communication framework in Go. HTTP server implementation for agent APIs with JSON-RPC support, task management, streaming capabilities, and message handling.
This MCP server has critical gaps in definition quality. Tool descriptions are present but generic and lack LLM-optimization guidance. Input parameters are documented at a high level but lack detailed constraints, types, and value descriptions. No output schemas are documented anywhere in the provided source code. The tools follow a hierarchical naming pattern (message/send, tasks/get) which is acceptable but not verb-first. Most critically, parameter schemas are INFERRED from the brief descriptions provided, no actual JSON Schema definitions are visible in the handler code, making it impossible to verify type information, constraints, or validation rules. The server appears to be early-stage or a prototype rather than production-grade.
Starts the agent execution for the message and waits for the final result.
Starts the agent execution and yields events as a stream using Server-Sent Events (SSE).
Attempts to cancel the task managed by the agent executor.
Retrieves a task by its ID.
Retrieves the push notification configuration for a task.
Sets the push notification configuration for a task.
Resubscribes to task events and returns a stream of events using Server-Sent Events (SSE).
No JSON Schema definitions visible for any tool input parameters. All schemas are inferred from brief text descriptions. Cannot verify parameter types, constraints, enums, or required fields. This violates the fundamental requirement that every parameter must have a type and description.
No documented output schemas for any tool. Cannot verify what fields are returned or their types. LLMs cannot plan downstream tool calls or extract required data without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Tool descriptions are generic and under 50 characters. Examples: 'Retrieves a task by its ID' (28 chars) is too brief for LLM selection reasoning.
Parameter descriptions are minimal or completely missing. Examples: 'The message to send, containing taskID, contextID, role, and parts' describes what a message contains but does not explain the expected format, constraints, or how to construct one. No description exists for the 'configuration' parameter.
Hierarchical tool names (e.g., 'message/send', 'tasks/pushNotificationConfig/set') are non-standard for MCP. Preferred pattern is verb_noun (send_message, set_push_notification_config). This complicates LLM parsing and tool discovery.
No error handling guidance documented. When tools fail (e.g., task not found, invalid config), there is no information in descriptions about what errors are retryable, what recovery steps exist, or what the LLM should do next.
Parameter naming lacks type suffixes. Examples: 'id' is ambiguous, could be task_id, message_id, or config_id. For 'taskId', unclear if it accepts only system IDs or also supports other identifiers.
No documentation of pagination, result limits, or batch operation support. Streaming tools (message/stream, tasks/resubscribe) lack documentation of event types, order guarantees, and when streams close.