Skip to main content
Glama
fosferon

gc_mcp

by fosferon

gc_workflow

Runs and manages YAML-defined deterministic workflows, supporting synchronous or async execution, listing, resuming, monitoring, and repairing workflow runs.

Instructions

Run deterministic workflows from ~/.config/gc/workflows/. Workflows are YAML pipelines with step types: tool, prompt, dispatch, shell, each, branch, halt.

Actions:

  • run (sync by default, or async: true)

  • list_workflows — list YAML definitions (defaults to summary: name/file/description/size)

  • list_executions — list past runs (defaults to summary: no runtime blob)

  • list — alias for list_executions (backward compat)

  • show (alias: get_execution) — one execution with full runtime

  • report — reliability summary, stale-running detection, recent failures

  • detail — per-step breakdown for an execution

  • context — inspect runtime context/keys for an execution

  • resume — re-run from a checkpoint

  • wait — bounded poll until terminal state or timeout

  • watch — stream daemon SSE continuity through MCP progress notifications, then return the terminal event

  • cancel — stop one execution and cancel any backing Oban workflow job

  • dismiss — hide an execution from default listings

  • delete — remove one execution (and checkpoint)

  • prune — bulk-delete old terminal executions

  • repair_stale — mark stale running executions failed and clear checkpoints

Response shaping:

run (sync): - Default shape: { execution_id, status: "complete", last_step, result }. result carries the last MEANINGFUL step's output — the shaper walks the trace backwards and skips nil-returning tail steps (gc.retain / gc.notify side-effects). last_step names whichever step produced result. If every step returns nil, result is null but last_step still names the actual final step. - select: "step_id" — return one specific step's result (bypasses the walk-past-nil default; use when you want an intermediate step or a specific side-effect's receipt). - select: "step_a,step_b" — return multiple specific steps (selected map + result unset). - return: "full" — everything (all step results + trace). - return: "steps" — all step results keyed by step_id, no trace. - return: "trace" — trace only, no results.

run (async: true): - Returns { ok: true, status: "started", execution_id } immediately. - Goes through Oban; survives daemon restart (idempotent resume — crash mid-run → row marked failed with reason "crashed-resume").

list_workflows: - Default: summary — name, file, description, size_bytes (no YAML body) - return: "full" — includes the YAML 'body' field for every workflow - select: "name1,name2" — return full bodies for the named workflows only

list_executions: - Default: summary — id, workflow, status, started_at, updated_at (no runtime blob) - return: "full" — includes 'runtime' JSON for every row (can be large) - select: "id,status" — return only the named fields per row

Use timeout to control client-side HTTP deadline, or "none" for no timeout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoExecution ID (for show/resume/detail/context/wait/watch).
keyNoContext key to inspect (for context action)
asyncNoIf true, run returns immediately with execution_id (run action only)
forceNoForce deletion of running execution (for action=delete)
limitNoMax rows for list_executions (default 20)
actionYesAction to perform
paramsNoJSON parameters for the workflow. Pass an object encoded as JSON, for example {"since":"2026-05-02T00:00:00+03:00","projects":["gc_daemon"],"mode":"draft"}. Use JSON arrays for list<string> params such as projects.
reasonNoDismiss reason (for action=dismiss)
returnNoResponse shape. run: "result" (default)/"full"/"steps"/"trace". list_workflows + list_executions: "summary" (default)/"full".
selectNoCherry-pick fields/steps. run: step IDs ("step_a,step_b"). list_workflows: workflow names (returns full body). list_executions: execution field names. Takes priority over return.
statusNoFilter list_executions by status (running/completed/failed/halted)
dry_runNoPreview repair_stale without mutating
timeoutNoClient-side HTTP timeout in seconds. Default: 300 (5 min) for run/resume, 15 for others. "none" / "infinity" / "infinite" disable timeout entirely. Accepts string-of-int ("600") so LLM stringification is safe.
intervalNoPoll interval in seconds for wait (default: 5). Accepts string-of-int.
workflowNoWorkflow name (for run/resume)
run_timeoutNoServer-side workflow execution timeout in seconds for action=run only. Distinct from client timeout. "none" / "infinity" / "infinite" disable the server-side run deadline.
execution_idNoExecution ID (alias for id)
include_hiddenNoInclude hidden rows in list/prune (default false for list, true for prune)
older_than_hoursNoMinimum age in hours for action=prune (default 24)
execution_timeoutNoAlias for run_timeout
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full disclosure burden and discharges it thoroughly: it details sync vs async behavior (Oban persistence, crash-resume semantics), the response-shaping default walk-past-nil logic, per-action return shapes, timeout defaults (300s for run vs 15s others), and that async survives daemon restart. This is rich, non-obvious behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but justified given the tool's 17 actions and complex response shaping. It's well-structured with clear section headers (Actions, Response shaping) and scoped bullet lists. A few redundancies exist (list/get_execution aliases and execution_id/id aliases are restated), but overall it front-loads the most important info and organizes the rest coherently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 20-parameter, 17-action tool with no output schema and no annotations, the description is remarkably complete: it details every action, the response-shaping variants, timeouts, async semantics, and failure recovery. The tool is genuinely complex and the description rises to that complexity. The only minor gap is it doesn't document the YAML step-type pipeline format in depth (tool/prompt/dispatch/shell/each/branch/halt), but those are named.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains the 'result'/'full'/'steps'/'trace' return-shape semantics, the 'select' priority behavior, the walk-past-nil default, and the 'walk-past-nil' last-step logic. It also clarifies timeout default durations which the schema only states generally. However, some params (interval, force, include_hidden, older_than_hours, dry_run) are only clarified by the schema, not the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource ('Run deterministic workflows from ~/.config/gc/workflows/') and immediately enumerates the 15+ distinct actions available, distinguishing the tool's multi-action surface clearly. The structured action list with per-action semantics makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear per-action guidance on when to use each action (run, list_workflows, show, resume, wait, watch, cancel, etc.). However, it doesn't explicitly name sibling tools as alternatives (e.g., gc_workflow_watch exists as a sibling for watching, and the description doesn't reference when to use gc_workflow vs gc_workflow_watch vs gc_run). That gap on cross-tool exclusions keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fosferon/gc_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server