Provides tools for interacting with GitHub repositories to manage fix-and-retry chains, including rerunning failed workflows and opening issues.
Monitors failing GitHub Actions workflows that opt in via a marker, automatically applies fixes with OpenCode, and retries the runs until they succeed or the retry budget is exhausted.
Monitor failing GitHub Actions workflows, auto-fix them with OpenCode,
and retry the run — driven by a workflow_run webhook, coordinated through an MCP server.
When a workflow that opts in via a # self-heal: true marker in its YAML fails, a
"fix-and-retry chain" is started: wait for the configured retry delays, run OpenCode
on a worktree of the failing branch to produce a fix, push it, re-run the workflow,
and on repeated failure open a GitHub issue. The MCP server surfaces the chains
(list_chains, get_chain, pause_chain, resume_chain, retry_now,
create_issue_now, set_config, health) to any MCP client.
GitHub Actions (workflow_run event)
│ POST /webhook/github (HMAC-SHA256 verified)
▼
Starlette webhook daemon ──► Service (chain state machine)
│ │
│ ├─► db (SQLite: chains / retries / events)
│ ├─► GitHub client (open issue, rerun)
│ └─► OpenCodeRunner (clone → fix → push)
▼
MCP server (stdio) ──► chain control tools for AI clientsTwo runnable entry points:
Daemon: python -m gh_workflow_fix — Starlette webhook server on port 18080
(configurable) plus a scheduler tick that picks up due chains.
MCP server: python -m gh_workflow_fix.mcp — stdio MCP server with the chain
control tools.
Related MCP server: cc-agent
pip install gh-workflow-fix-mcpRequires Python >= 3.11 and OpenCode installed for the fix
runner (the binary path is set with OPENCODE_BIN; it must be able to push to the
repository of the failing workflow).
All settings come from environment variables. Only GH_TOKEN, GH_REPO,
GH_OC_AUTO and WEBHOOK_SECRET are required.
Variable | Required | Description | Default |
| yes | GitHub PAT with | — |
| yes | Repository to monitor, | — |
| yes | Automatically run OpenCode fixes ( | — |
| yes | Secret for HMAC verification (same value as the GitHub webhook) | — |
| no | Marker comment that opts a workflow into self-healing |
|
| no | Comma-separated delays (minutes) before attempts 1, 2, 3… |
|
| no | Where DB and worktrees live |
|
| no | Path to the |
|
| no | Model to pass to | unset |
| no | GitHub API base URL (for GHES) |
|
| no | Bind address of the daemon |
|
| no | Timeout for a single OpenCode fix run |
|
| no | Scheduler tick interval in seconds |
|
A workflow only becomes a fix candidate when its YAML contains the marker
(default # self-heal: true) as a comment. For example:
name: CI
# self-heal: true
on:
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo helloRepository → Settings → Webhooks → Add webhook.
Payload URL: https://your-host:18080/webhook/github.
Content type: application/json.
Events: "Let me select individual events" → Workflow runs (workflow_run).
Secret: the same value as WEBHOOK_SECRET.
Save; GitHub sends a test ping which is ignored — only workflow_run events are
processed.
Only failing runs of opt-in workflows create chains; successful runs are recorded in the events table and ignored.
export GH_TOKEN=... GH_REPO=owner/repo GH_OC_AUTO=true WEBHOOK_SECRET=...
python -m gh_workflow_fixThe daemon exposes POST /webhook/github (HMAC verified) and GET /healthz
({"ok": true, "db": ..., "tick": ...}).
Add to your MCP configuration, e.g. for OpenCode (opencode.json):
{
"mcp": {
"gh-workflow-fix": {
"type": "local",
"command": ["python", "-m", "gh_workflow_fix.mcp"],
"enabled": true
}
}
}The MCP server reads the same environment as the daemon. Run it locally on the same
machine as the daemon (they share DATA_DIR/state.db).
Tool | Description |
| List fix-and-retry chains, optionally filtered by state |
| Get a single chain by ID |
| Schedule a chain for immediate retry |
| Pause a chain (only if running, waiting, or fix_error) |
| Resume a paused chain |
| Create a GitHub issue for a chain |
| Set a config override ( |
| Health check with DB status and chain counts |
running → fix attempt on a worktree → either waiting (fix pushed / rerun set,
waiting for the next run event) or fix_error (fix runner failed, next retry
scheduled) → after the retry delays are exhausted: done or exhausted.
exhausted chains have a GitHub issue opened.
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytestCreate a GitHub issue for a chain (requires GitHub client).
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only notes the dependency on a GitHub client but does not disclose side effects, required permissions, reversibility, or what happens on successful creation. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states both the purpose and a key prerequisite without extraneous words. It is concise, though it is also sparse and could include more useful detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered, but the description leaves open what a 'chain' is, how chain_id should be obtained, and what 'requires GitHub client' entails (e.g., authentication, availability, setup). For a create operation, it does not provide enough context for an agent to confidently invoke it without prior knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'for a chain' weakly maps chain_id to a chain identifier, but it does not explain how to obtain the chain_id, what constraints apply beyond type integer, or what a chain represents in this context. The semantic value added is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-resource pair ('Create a GitHub issue') and scopes it to a chain, which distinguishes it from sibling tools like list_chains, get_chain, retry_now, pause_chain, resume_chain, set_config, and health. An agent can tell exactly what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does ('create a GitHub issue for a chain') and includes the prerequisite 'requires GitHub client.' However, it provides no explicit guidance on when to use this instead of siblings, nor any exclusion conditions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single chain by ID, or error if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does state that a missing ID produces an error rather than an empty result, which is useful. However, it does not explicitly confirm read-only behavior, permissions, or any other runtime side effects, though 'get' implies a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler: 'Get a single chain by ID, or error if not found.' Each clause adds useful information—scope, parameter, and error behavior. For a tool with a single parameter, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-by-ID with an output schema, so the description need not explain return values. It covers the core behavior and error case, and the single parameter is simple. Still, it never situates itself relative to list_chains or states prerequisites for obtaining a valid chain_id, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter chain_id is documented only as an integer. The description merely says 'by ID', which mirrors the parameter name and adds no information about where the ID comes from, valid values, or format. With low schema coverage, the description fails to substantially compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('get'), resource ('chain'), and scope ('single chain by ID') in one sentence. The error-if-not-found clause adds precision, and the 'single' scope implicitly differentiates it from the sibling list_chains. This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching exactly one chain when you know its ID, but it never mentions when to use this instead of list_chains or the other siblings. There are no explicit exclusions, prerequisites, or alternative tool references. Usage is only implied by the verb and scope, so it stays at a minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check with DB status and chain counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It does so by disclosing what is checked: DB status and chain counts. It also implies a read-only, non-mutating nature, which is important because the sibling list includes mutating tools like retry_now and pause_chain. However, it does not describe response format or any side effects, though a health check is generally read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the tool's purpose and scoped to its key outputs. No filler or redundant information. It earns a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool with an output schema present, the description is largely complete. It states the tool's scope (DB status and chain counts), and the output schema presumably documents the return shape. It could mention whether the tool fails or errors when the DB is down, but this is minor given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the description does not need to explain parameter details. The schema already confirms no parameters are accepted. The description adds meaningful scope information about what the health check covers (DB status and chain counts), which is more than the empty schema conveys. Baseline 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Health check with DB status and chain counts.' It is distinguishable from sibling tools, which focus on chain operations, retries, and config, even though it shares the 'health' concept with the title. It is succinct and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is a health check, but it does not explicitly state when to use it versus alternatives such as list_chains or get_chain. There are no other health-related siblings, so the usage is implied rather than exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List fix-and-retry chains, optionally filtered by state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that filtering by state is optional, but doesn't mention whether the operation is read-only, what the output looks like, pagination, or any side effects. For a list operation this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the main action and includes the key optional filter. No wasted words, though it could add a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema present, the description is mostly adequate. However, with no annotations and no mention of valid state values or read-only behavior, an agent might not know what states are available or whether this is a safe read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does mention the 'state' parameter and that it's an optional filter, which adds meaning beyond the raw schema. However, it doesn't specify valid state values or the effect of null/default, leaving the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('fix-and-retry chains'), and mentions an optional filter by state. It distinguishes itself from siblings like get_chain (singular) and retry_now/pause_chain/resume_chain (actions on a chain), though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the listing/read tool for chains, and the optional state filter suggests when it might be used. However, it doesn't explicitly state when to use this vs get_chain, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a chain (only if running, waiting, or fix_error).
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries more weight. It discloses a key behavioral precondition (only valid in certain chain states), but does not explain what happens if the precondition is violated, whether the action is reversible, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. The core action comes first and the condition is included compactly in parentheses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the essential action and the state constraint. It is slightly incomplete around error behavior and postconditions, but the low complexity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions chain_id or how it should be used. The parameter name is self-explanatory and the schema defines it as a required integer, but the description adds no semantic value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Pause a chain'. The parenthetical 'only if running, waiting, or fix_error' gives the exact scope and differentiates it from sibling tools like resume_chain and retry_now.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly says when the tool is applicable by restricting use to running, waiting, or fix_error states. It does not explicitly name alternative tools for other states, but the condition alone provides a clear usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a paused chain.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It says the chain is resumed but does not mention side effects, idempotency, error conditions, or whether resuming triggers immediate execution. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. Every word adds value by specifying both the action and the target state, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the basic invocation context adequately. However, with no annotations and no guidance on effects or prerequisites, it remains only minimally viable rather than fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining chain_id, but it only adds that the chain is paused. The meaning of chain_id is largely inferred from the parameter name rather than explained, and there is no additional detail about format, ownership, or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resume') and a clear resource ('a paused chain'), which precisely identifies the operation. It also naturally distinguishes this tool from siblings like pause_chain and retry_now without needing extra explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'paused chain' implies the tool should be used when a chain is paused seatbelt, but the description gives no explicit guidance about when not to use it or how it differs from retry_now or other alternatives. Usage is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a chain for immediate retry.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but 'schedule' only vaguely implies a side effect. It does not say whether scheduling is idempotent, whether it replaces an existing retry, whether it mutates chain state, or whether it requires a current run to be finished.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no filler and is appropriately front-loaded. It is concise, though at the cost of omitting useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has a single parameter, and provides an output schema, but the description still leaves key gaps: no guidance on when a retry is valid, no explanation of scheduling semantics, and no behavioral context. An agent can only guess at the effects or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain chain_id beyond echoing the schema property name. The integer type and required flag are helpful, but the description adds no meaning about what the identifier must reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and object: 'Schedule a chain for immediate retry.' This makes it distinct from sibling tools like list_chains or pause_chain, though it does not explicitly name the alternative it should not be confused with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no conditions for when retry_now should be chosen instead of resume_chain or create_issue_now, nor does it mention prerequisites such as the chain being in a failed or paused state. An agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a configuration override (gh_oc_auto or retry_delays_min).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose side effects. It only says 'override,' implying mutation but not explaining persistence, scope, or reversibility. It also doesn't mention any permissions or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, and the key enumeration is the only extra detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, an agent needs value-format semantics and usage context to call it correctly. The output schema covers return shape, but the description leaves the input value format and behavioral effects unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only source of parameter meaning. It names the two valid keys, adding real value over the generic string schema, but it does not describe the expected value format for either key (e.g., boolean vs numeric minutes).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Set a configuration override') and enumerates the exact allowed keys ('gh_oc_auto or retry_delays_min'), making the tool's function unambiguous and distinct from all sibling chain-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or exclusions. Usage for setting those two override keys is implied by the wording, and since no sibling tool handles configuration, there are no named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_issue_nowget_chainhealthlist_chainspause_chainresume_chainretry_nowset_configScored across 8 tools
Each tool targets a distinct action or resource: listing/getting chains, retrying, pausing/resuming, creating issues, config, and health. There is minor potential confusion between retry_now and resume_chain since both make a chain active again, but the descriptions clarify the difference. Overall, boundaries are clear.
Most tools follow a verb_noun pattern: list_chains, get_chain, pause_chain, resume_chain, set_config. Minor deviations include health (bare noun) and create_issue_now (verb_noun_adverb), but these are still readable and do not break the overall convention.
Eight tools is a well-scoped set for a fix-and-retry workflow server. Each tool covers a necessary operational aspect: inspection, state changes, issue creation, configuration, and health monitoring. No tool feels redundant or extraneous.
The tool surface covers the core lifecycle of chains: list, get, retry, pause, resume, plus config and health. A delete/cancel operation is missing, but it may not be needed for this domain. Minor gap, but agents can generally operate without dead ends.
MCP-native AI SRE: ask what's broken in production, get a reviewed GitHub fix PR.
Open-source Zapier/n8n alternative as an MCP server: agents build, run and debug your workflows.
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
Triage failing GitHub Actions jobs and see what self-heal repaired, in natural language.
