Workflow recipes and resources
Besides tools, the Orcho MCP server publishes two discovery surfaces:
- Workflow recipes — published prompts that guide a client through a multi-step job. The server does not execute them: the client reads the steps and calls the tools itself, in order, with its own judgment at each gate.
orcho://resources — addressable, read-only artifacts. A client can fetch one slice of run state by URI instead of calling a tool and parsing a full snapshot.
Both exist so a client does not have to reverse-engineer multi-call workflows from individual tool descriptions.
If you have not configured MCP yet, start with Start with MCP. For the tool-by-tool lifecycle surface these recipes compose, read MCP control surface.
Workflow recipes
Section titled “Workflow recipes”Each recipe is an MCP prompt. Clients that support prompts (Claude Code, Cursor, and others) surface them as slash commands; invoking one injects the step-by-step guidance into the conversation.
| Recipe | What it walks the client through |
|---|---|
orcho_getting_started | First-contact walkthrough: workspace check, profile choice, first run, watching progress, the QA gate flow, and reading final evidence. |
orcho_plan_then_implement | Two-step pipeline: spawn a planning-profile run, review the parsed plan at the pause, then spawn a from_run_plan child run on the feature profile. |
orcho_followup_from_plan | Spawn an implementation run that inherits the parsed plan from an existing parent run, skipping the planning block. |
orcho_review_paused_run | Inspect a run paused on a phase handoff and propose a decide action: continue, retry_feedback, continue_with_waiver, or halt. |
orcho_halt_with_reason | Terminate a paused run via a phase-handoff halt with a structured audit-trail note explaining the reason. |
orcho_resume_failed_run | Classify a stopped run’s state first, then resume from checkpoint when resumable — or route to from_run_plan when it is not. |
orcho_observe_active_run | Follow an in-flight run with a resilient loop: short bounded watch, event-summary fallback on disconnect, reconnect from the cursor. |
orcho_inspect_delivery_gate | Classify a stopped run’s post-release delivery or correction gate and resolve it through orcho_delivery_decide, never by applying the retained diff by hand. |
Tools-only clients discover the same catalogue without prompt support: the
orcho_workflows_list tool and the orcho://workflows resource both return
the recipe names, descriptions, and arguments.
Resources
Section titled “Resources”Every resource is a read-only projection of durable workspace or run artifacts. Most return JSON; the exceptions are noted.
| URI | Content |
|---|---|
orcho://workspace | Resolved workspace dir, runs dir, and recent project paths. |
orcho://runs | Recent pipeline runs, newest first. |
orcho://runs/{run_id}/meta | meta.json for a single run. |
orcho://runs/{run_id}/metrics | metrics.json: token counts, durations, per-phase split. |
orcho://runs/{run_id}/events | Full events.jsonl stream (newline-delimited JSON). |
orcho://runs/{run_id}/summary | Latest bounded event summary for a run. |
orcho://runs/{run_id}/parsed_plan.json | Durable parsed-plan artifact. |
orcho://runs/{run_id}/evidence | Composed evidence bundle for a run. |
orcho://runs/{run_id}/diff.patch | Captured unified diff (text/x-patch). |
orcho://runs/{run_id}/phases/{phase}/diff.patch | Captured per-phase diff (text/x-patch). |
orcho://profiles | Pipeline profile catalogue. |
orcho://profiles/{name} | A single pipeline profile by name. |
orcho://projects/{project_b64}/skills | Agent Skills discovered for the project (same registry as orcho_skills_list). |
orcho://workflows | Workflow recipe catalogue (the table above, as data). |
orcho://docs/getting-started | The getting-started walkthrough as markdown — same content as the orcho_getting_started prompt, for URI-based discovery. |
When to prefer a resource over a tool
Section titled “When to prefer a resource over a tool”Resources are addressable, cacheable reads. A URI names one artifact, so a
client can refresh exactly the slice it cares about — re-reading
orcho://runs/{run_id}/meta is cheaper than calling orcho_run_status and
receiving the whole snapshot again.
Tools are parameterised queries and actions. Use a tool when you need
arguments beyond the URI (an event cursor, an evidence slice name, a bounded
watch), when you want typed next_actions attached to the answer, or when
you are changing state rather than reading it.
A practical split:
- polling one known artifact repeatedly — resource;
- asking “what happened since sequence N” — tool (
orcho_run_events_summary); - deciding, resuming, halting, delivering — always a tool.