Missing fire_cue tool: agents can't trigger existing cues via MCP

[mikemolinet]

The gap

The current 8-tool surface covers create / list / get / pause / resume / delete / list_executions / report_outcome — but there's no MCP tool for "fire an existing cue right now."

cueapi_create_cue schedules a NEW cue. There's no equivalent for invoking an existing one immediately, even though POST /v1/cues/{id}/fire already exists in the CueAPI HTTP API.

Why it matters

This came up independently in two MCP-host environments within the same hour today:

1. An agent in Claude Desktop / Cowork-style tooling trying to send a cue from in-session.
2. An agent in Claude Code trying to use cues as a lightweight messaging channel between agents (carrying { message, instruction, task, reply_cue_id } in payload_override).

In both cases the agent had to fall back to raw HTTP via shell because no MCP tool exposed the fire endpoint. That's:

• A worse UX (agents must know HTTP + auth + payload conventions)
• A discoverability problem (an agent surveying its MCP toolbox doesn't see "fire a cue" as an option, so doesn't know coordination via cues is possible without consulting docs)
• Friction for agents in environments where shell tooling is restricted

Proposed fix

Add cueapi_fire_cue({ cue_id, payload_override?, merge_strategy? }). Wraps the existing POST /v1/cues/{id}/fire endpoint. No backend changes.

PR: #7