A production-grade MCP (Model-Context-Protocol) server for Hedera that integrates Hedera Agent Kit and @hashgraphonline/standards-agent-kit to support HCS-1, HCS-2, HCS-3, HCS-10, and HCS-11 standards. The server exposes RESTful APIs and an SSE-based MCP interface for decentralized AI agent communication.
The Hedera MCP server has 7 tools with explicit Zod schema registration and descriptions. However, significant gaps in parameter descriptions, output schema documentation, and error handling reduce overall quality. Tool names follow verb_noun conventions (register_agent, find_agents, request_connection, accept_connection, list_connections, send_message, get_messages), which is positive. However, parameter descriptions are minimal or absent, and critical security concerns exist around credential handling. Most parameters lack constraints (enums, ranges), and return types are not formally documented. The server does not implement tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having both read-only and write operations. Error handling is absent, tools return string summaries or JSON without guidance on recovery or categorization.
Accept a pending connection request from another agent.
Search for registered agents by name or capability.
Fetch recent messages from a connection.
List active connections for an agent.
Create and register a new AI agent on Hedera (HCS-10/HCS-11). If no account is provided, generates a new one.
Request a communication connection with another agent.
Send a message over an established connection.
CRITICAL: Private keys and credentials exposed as tool parameters (register_agent, request_connection, accept_connection, send_message). This violates the secret-injection pattern and creates a security vulnerability: credentials will be logged in agent traces, prompts, and call histories.
Output schemas are not documented. Tools return JSON or string summaries but the structure and field types are not declared. LLMs cannot reliably extract required fields for chaining to downstream tools.
Parameter descriptions are minimal or missing. Parameters like 'accountId', 'capabilities', 'limit', 'connectionTopicId' have no description text explaining their meaning, format, or constraints. Zod schema types are present but descriptions are absent or generic.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with 'Risk: READ_ONLY' or 'Risk: WRITE' in metadata but MCP tool annotations are not present in the schema. Agents cannot distinguish safe retry operations from destructive ones without manual reasoning.
No error handling or recovery guidance. Tools return bare strings or JSON without context on failure cases. No indication of retryability, user-fixable errors, or what action to take next if a call fails.
No input validation or constraint documentation. Parameters like 'capabilities' (array of numbers) lack specification of valid codes. 'limit' has no min/max bounds. 'message' has no length limit. LLMs may pass invalid values; tools should document constraints (enum, range, pattern) to guide correct invocation.
No pagination support beyond a basic 'limit' parameter. Tools like find_agents and list_connections have no offset, cursor, or total count to enable safe iteration over large result sets. LLMs cannot reliably iterate across pages.
Insufficient parameter context for chaining. Response documentation is missing, making it unclear which IDs and references downstream tools need. For example, register_agent returns 'accountId' and 'privateKey' but doesn't indicate these are required for request_connection, accept_connection, and send_message.
No idempotency hints or retry guidance. Tools like send_message don't state whether retry with the same parameters is safe. Agents may hesitate to retry on ambiguous failures, or may accidentally double-send messages.