Hermes as an MCP Messaging Bridge

Hermes can connect to MCP servers, and it can also run as one. In server mode, another MCP-capable client can list conversations, read messages, fetch attachments, observe events, send messages, and respond to pending approvals through Hermes's channel bridge.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp#running-hermes-as-an-mcp-server

Choose this pattern carefully

Use the bridge when an external coding or operations client needs controlled access to Hermes conversations. Do not add it merely to avoid opening the normal Hermes interface. Messaging tools act on real channels and should remain narrower than a general automation account.

Bridge checklist

[ ] Start the stdio server under the intended Hermes profile.
[ ] Confirm the client launches hermes mcp serve rather than a different profile alias.
[ ] Begin with conversation listing and message reads.
[ ] Treat attachments and message bodies as private, untrusted data.
[ ] Restrict send operations to approved channels and workflows.
[ ] Keep human approval responses visible and attributable.
[ ] Track event cursors and handle reconnects without assuming old events remain queued.
[ ] Verify the messaging gateway is running before testing sends.

Read and send have different dependencies

Read operations can use Hermes session storage without the messaging gateway running. Sending needs active platform adapters, so a healthy MCP process does not prove outbound delivery is available. Check the gateway and verify the destination message.

The event queue is in memory and begins when the bridge connects. Use message-history reads for older context rather than assuming an event poll can replay everything since the last machine restart.

Pitfalls

Exposing all conversation history to an untrusted MCP client.
Treating an in-memory cursor as durable archival state.
Reporting a send as successful without checking the platform.
Letting a client approve high-impact actions without a human-visible policy.
Running the bridge under the wrong profile and reading the wrong session database.
Assuming the MCP bridge starts or supervises messaging gateways.

Verification steps

Start the MCP bridge from the intended profile.
List channels and conversations and verify only expected data appears.
Read one known non-sensitive test conversation.
Poll and wait for a synthetic message event.
With the gateway running, send a harmless test message to a dedicated channel.
Confirm the exact message appears once on the platform.
Disconnect and reconnect, then verify old context through message history rather than the new event queue.