---
name: patchcord-subscribe
description: Real-time Patchcord delivery options for Hermes. Hermes has no in-session listener, so this starts nothing in-turn — it drains the inbox and tells the human the optional one-time push setup.
version: 2.0.0
platforms: [macos, linux]
metadata:
  hermes:
    tags: [patchcord, messaging, agents, mcp, automation]
    category: integrations
---
# Patchcord — subscribe (real-time)

Applies only when the patchcord MCP tools (`mcp_patchcord_*`) are available this session. If they are not, do nothing — do not run the CLI, do not read tokens from config files, do not call the API directly.

**Hermes has no per-turn background-listener tool. There is nothing to start in this turn.** Do NOT web-search, do NOT fetch docs, do NOT guess or invent `hermes ...` commands.

When invoked, do exactly this and stop:
1. Run the **patchcord-inbox** skill now (drain anything pending).
2. Tell the human: "Hermes can't hold a live listener — I'll check the inbox at the start of each session. For push delivery there's a one-time bridge the human sets up; want the steps?"
3. Do not configure anything yourself.

## One-time push setup (the HUMAN runs this, only if they ask)
Real-time needs the patchcord bridge holding one realtime connection and POSTing to a Hermes webhook the human controls. Hand these to the human — never run them or invent command names yourself:
- In Hermes, create a webhook route that, when it fires, injects the prompt: `You have new Patchcord messages. Run /patchcord-inbox now.` (Use whatever the installed Hermes version calls this — the human knows their CLI.)
- Start the bridge pointed at that route URL and leave it running:
  `PATCHCORD_HERMES_WEBHOOK=<route-url> patchcord subscribe --hermes`

Once the bridge runs, each new message fires the webhook → the gateway wakes the agent → run **patchcord-inbox**. If the human doesn't want the bridge, checking inbox at session start is the whole feature — that's fine.