hermes - 💡(How to fix) Fix [Feature]: Let an MCP client task the Hermes agent via a one-shot cron job

Problem or Use Case

hermes mcp serve lets an MCP client (Claude Code, Cursor, etc.) observe conversations and send messages — but a message sent via messages_send goes out as Hermes's own bot identity. The Hermes agent never receives it as a prompt, so an MCP client has no way to hand the Hermes agent a task and have it executed.

This is a real gap for multi-agent setups. A coding agent often wants to delegate a unit of work to Hermes — which has the logged-in browser sessions, connected messaging platforms, and long-term memory the coding agent lacks — and get the result back. Today it can only watch and post-as-the-bot.

Related: #21563 and #22300 establish that the MCP bridge subprocess has no IPC channel to the gateway; docs PR #27521 just documented that the bridge therefore cannot task the agent. This issue proposes closing that gap in a way that respects the decoupling.

Proposed Solution

A new MCP tool (working name agent_task) that enqueues a one-shot cron job:

• Args: prompt (the task), deliver_to (a conversation/target the agent's result is delivered to), optional enabled_toolsets / workdir.
• It registers a one-shot cron job via the existing cron/jobs.py job-creation path, scheduled for the next run, with prompt_text=prompt.
• The gateway's already-running cron scheduler picks it up and runs the agent; the output is delivered to deliver_to.
• Returns the created job id so the MCP client can poll events_wait / messages_read for the result.

Why this fits the existing architecture: it is IPC-free. The MCP server writes the job to the shared cron-jobs store; the gateway's scheduler reads it — the same file-mediated pattern the bridge already uses to read sessions.json and the session DB. It does not need the live gateway-to-bridge IPC channel that #21563 / #22300 establish does not exist. It extends the bridge as a stateless shim rather than fighting that design.

(Note: this is a tool on the hermes mcp serve bridge surface, not an agent capability — the skill-vs-tool guidance does not apply; "expose a new MCP-server tool" cannot be a skill.)

Open questions for maintainers

I would rather get design steer before writing code:

1. Is a one-shot cron job the right primitive, or would you prefer a different mechanism?
2. Does the cron system cleanly support a "run once, then remove" job, or would that need a small addition?
3. An MCP client scheduling agent work — acceptable as-is (the MCP client is already locally trusted), or should it be opt-in behind a config flag?
4. Tool naming and argument shape.

Alternatives Considered

• Direct bridge-to-gateway IPC so the bridge can inject an inbound message — rejected; #21563 / #22300 show the bridge is deliberately gateway-decoupled.
• Routing messages_send into the agent — wrong; messages_send is the agent's outbound path, conflating it would break its semantics.
• Spawning a separate hermes agent subprocess from the tool — heavyweight, bypasses the live gateway, loses session continuity.

Feature Type

New tool (on the hermes mcp serve bridge surface).

Scope

Medium — likely mcp_serve.py plus a thin call into the existing cron job API, plus tests.

Contribution

• I'd like to implement this myself and submit a PR (pending design steer on the questions above).