Docs Reference

Using the flower MCP

flower exposes the same query path to agents (MCP) and to you (web UI). This is the short guide for an agent — Claude Code, Codex, Pi — that wants to use flower to recall context and drive the brief workflow.

Connecting

flower registers one MCP server (flower) over two transports:

stdio — add it to a project's .mcp.json and boot with php artisan mcp:start flower (run from the flower app root).
HTTP — http://flower.test/mcp, served by Herd.

Tools are negotiated at connection time. If you enable flower mid-session, reconnect so the tools appear.

Recall tools (read-only)

All recall_* tools are read-only and idempotent. Scope nests as worktree ⊂ project ⊂ global.

Tool	When to use
`recall_resume(project?, worktree?)`	Start here. Pick work back up: the most-recent unfinished segment — goal, status, next_steps, files, commits-since.
`recall_search(query, scope, …)`	Hybrid keyword + vector lookup across segments, scratchpads, todos, commits, briefs. "Has this been touched before, anywhere?"
`recall_touching(path_or_symbol, scope?)`	Everything that changed or mentioned a path/symbol.
`recall_file_story(path, scope?)`	The session-level history of one file — why it changed, tied to the goals it served.
`recall_open_loops(project?)`	Unfinished sessions + in-progress segments + open todos.
`recall_active(scope, project?, worktree?)`	Who is live/idle right now in a scope — the roster's liveness, as data.
`recall_health()`	Compact warnings about flower's own ingest / MCP / hook-integration health.

Beyond these, each workflow surface has its own reads that return exactly what the matching UI shows: recall_brief / recall_briefs / recall_dispatch_queue (briefs), recall_roster / recall_signals / recall_compaction (daemons), recall_decisions (decisions assigned to you), recall_inbox (operator notes), recall_charters (daemon charters), and recall_projects.

Briefs

The brief workflow is fully scriptable. Reads are recall_brief, recall_briefs, recall_dispatch_queue. Writes each require an actor_ref (which auto-attaches you as a participant):

Tool	What it does
`brief_create` / `brief_update_spec` / `brief_append`	Open a brief, overwrite its spec (prior snapshotted), append a trace event.
`brief_ask` / `brief_open_questions` / `brief_answer`	Open async operator questions on a brief, list the open ones, record an answer.
`brief_dispatch` / `brief_claim` / `brief_dispatch_complete` / `brief_dispatch_cancel`	Create a dispatch packet, claim it, mark it done or cancel a dead dispatch (completion returns newly-unblocked briefs).
`brief_request_review` / `brief_review`	Hold a finished brief at `in_review`; submit a PASS / REQUEST_CHANGES / BLOCK verdict (only PASS completes).
`brief_set_parent` / `brief_depend` / `brief_undepend` / `brief_merge`	Group under an epic; add/remove dependency edges (cycle-guarded); merge duplicates into a survivor.

A brief with any incomplete dependency cannot be dispatched — you'll get a clear "blocked by #X". Complete the blocker and its dependents come back as dispatchable.

Decisions & the operator inbox

Two async, non-interrupting channels between agents and the operator (writes need an actor_ref):

Decisions — the /decisions "waiting on your call" board. Open one with decision_ask (a confirm / choice / text prompt), pull the ones released and assigned to you with recall_decisions, and mark receipt with decision_ack (a delivered-once ledger). The operator answers in the UI; decision_answer is that same write over MCP.
Operator inbox — the /inbox, where the operator drops async "handle later" notes for a project's orchestrator. Read with recall_inbox; manage with note_create / note_update_status / note_reassign / note_unassign.

Daemon coordination

If you're a standing daemon, you also keep yourself on the roster and coordinate handoffs through the daemon_* tools — daemon_checkin (heartbeat), the compaction / reset / wind-down lifecycle, and the durable signal queue (recall_signals → signal_claim → signal_complete / signal_fail). The full lifecycle is on Daemons & the roster.

Feedback

Tool	When to use
`flower_feedback(kind, summary, detail?, context?)`	Report a `bug` / `note` / `idea` / `mcp_issue`. Persists a record you triage at `/feedback`.

Reach for it whenever a recall_* tool returns a surprising or wrong-shaped result, flower errors, or you spot an improvement. Put the offending tool + args

what you observed in context. You are dogfooding flower as it is built — reporting is the point.

Debug-mode tools (gated)

These appear only when settings.debug_mode is on:

flower_pipeline_status — ingest/segment/embed health (see the ingest pipeline).
flower_session_raw — the raw events/usage flower parsed for one session.
flower_reindex — request a re-ingest/re-index (not read-only).

If a debug tool is missing, debug-mode is off — that's expected, not a bug.

Where to look when flower misbehaves

Sentry — unhandled exceptions (project "flower").
Horizon — queue/job failures across the pipeline.
storage/logs/laravel.log — graceful-degradation warnings.
The debug tools above — to see where sessions are stuck.