Durable Hermes A2A gateway with a Desktop MCP client and managed SSH transport
Hermes A2A Gateway exposes 10 tools with basic naming and minimal descriptions. Tool names follow verb_noun convention (SendMessage, GetTask, ListTasks, CancelTask, etc.), which is positive. However, descriptions are extremely terse (10-50 chars), providing almost no context for LLM selection. Input schemas are present but sparse: parameters lack type information beyond 'object' and 'string', with no enums, constraints, or validation guidance. No output schemas are documented. Error handling is not visible in the tool definitions. The adapter code shows JSON-RPC routing but no evidence of recovery guidance, categorized errors, or actionable error messages. Security considerations (secret injection, permission gates, audit trails) are not evident in the tool interface. Overall, this is a minimal implementation suitable for A2A protocol bridging but inadequate for autonomous agent reasoning.
Cancel a running task
Create a push notification configuration for task updates
Delete a push notification configuration
Retrieve a task by ID
Retrieve a push notification configuration
List push notification configurations
List tasks with optional filtering and pagination
Descriptions are critically sparse (10-50 chars). LLMs cannot determine when to select SendMessage vs SendStreamingMessage, or why to call SubscribeToTask instead of GetTask. Descriptions must explain WHAT, WHEN, and WHAT IT RETURNS (50-200 chars minimum).
Input schemas lack type constraints and validation guidance. Parameters are typed as 'object' or 'string' with no enums, patterns, length limits, or format specifications. E.g., 'limit' in ListTasks has no min/max; 'contextId' has no format hint. LLMs cannot validate inputs before calling.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Send a message to an agent and receive a response
Send a streaming message to an agent and receive streamed responses
Subscribe to task status updates via streaming
No output schemas documented. LLMs do not know what fields to expect from GetTask, ListTasks, or SubscribeToTask responses. This prevents downstream tool chaining and forces agents to guess field names.
No error handling guidance visible. Tool definitions do not indicate what errors are retryable, user-fixable, or fatal. No recovery hints (e.g., 'If task not found, try ListTasks first'). Agents will not know how to respond to failures.
No security declarations visible. Tools that modify state (SendMessage, CancelTask, CreateTaskPushNotificationConfig, DeleteTaskPushNotificationConfig) do not declare required permissions or audit requirements. No evidence of secret injection or permission gates.