hermes-mcp-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HERMES_BRIDGE_API_KEY | Yes | API key for the Hermes Gateway. Must match API_SERVER_KEY in ~/.hermes/.env. | |
| HERMES_BRIDGE_API_URL | No | URL of the Hermes Gateway (default: http://127.0.0.1:8642). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hermes_askA | Delegate a task to Hermes Agent on this user's machine. Use for things the calling LLM cannot do directly: scheduling cron jobs, browser-driven web search, sending email, creating/editing local documents, anything that should persist after this chat ends. Args: prompt: Natural-language instruction for Hermes. session_id: Optional. Pass the same id across multiple calls in one chat to let Hermes remember prior steps (draft → refine → save). profile: Optional. Hermes profile to use (e.g. 'default', 'general_researcher'). Overrides the model in config.toml. Discover available profiles via the gateway's /v1/models endpoint. Returns: Hermes's final answer text. |
| hermes_checkC | Not implemented. Kept for API parity with hermes-mcp. |
| hermes_cancelA | Not implemented. Kept for API parity with hermes-mcp. |
| hermes_resetA | Not implemented. Kept for API parity with hermes-mcp. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
All four tools have distinct names and clear descriptions. The three non-functional tools are explicitly marked as 'Not implemented', so an agent can easily distinguish the single functional tool from the stubs.
All tool names follow a consistent 'hermes_verb' pattern with imperative verbs (ask, cancel, check, reset), which is predictable and systematic.
With only one functional tool out of four, the effective tool count is very low for a server that claims to handle diverse tasks like scheduling, browsing, and email. The three stubs inflate the count without adding value.
The server is missing core lifecycle operations: there is no way to cancel a task, check its status, or reset a session, even though stubs for these exist. The single 'ask' tool cannot cover the full intended scope.