Describe the feature or problem you’d like to solve
GitHub MCP already exposes workflow runs, jobs, and logs. The remaining gap is waiting for CI without making the agent supervise it.
Today, an agent must repeatedly poll actions_get or block on gh run watch. Discussion #1088 recommends polling every 15–30 seconds. That keeps the agent occupied with orchestration instead of useful work.
The 2026-07-28 MCP specification introduced Tasks for long-running asynchronous operations. Workflow monitoring is a natural fit.
Proposed solution
Add an Actions operation that waits for a workflow run as an MCP Task:
{
"method": "watch_workflow_run",
"owner": "github",
"repo": "github-mcp-server",
"run_id": 123456789,
"until": "completed"
}
It would return immediately with a Task handle:
{
"resultType": "task",
"taskId": "gh-actions-run-123456789",
"status": "working"
}
GitHub MCP would own the wait, completing the Task when the run reaches a terminal state. Clients could use tasks/get or task subscriptions instead of making the model poll Actions.
This requires no webhook, tunnel, or inbound connectivity for a local server. On failure, the Task could optionally return failed jobs and relevant log tails using existing Actions capabilities.
Example prompts or workflows (for tools/toolsets only)
- “Push this fix and watch CI. If it fails, investigate the failing job.”
- Agent pushes → starts workflow Task → CI fails → Task returns failed-job context → agent fixes and pushes again.
- “Trigger the deploy workflow and tell me when it finishes.”
- “Watch this run; only bring me back in if something fails.”
Additional context
GitHub MCP already has the Actions data plane. What is missing is the asynchronous waiting primitive.
Before MCP Tasks, client-driven polling was a reasonable workaround. Tasks now provide a protocol-native lifecycle for this operation.
Related:
Describe the feature or problem you’d like to solve
GitHub MCP already exposes workflow runs, jobs, and logs. The remaining gap is waiting for CI without making the agent supervise it.
Today, an agent must repeatedly poll
actions_getor block ongh run watch. Discussion #1088 recommends polling every 15–30 seconds. That keeps the agent occupied with orchestration instead of useful work.The 2026-07-28 MCP specification introduced Tasks for long-running asynchronous operations. Workflow monitoring is a natural fit.
Proposed solution
Add an Actions operation that waits for a workflow run as an MCP Task:
{ "method": "watch_workflow_run", "owner": "github", "repo": "github-mcp-server", "run_id": 123456789, "until": "completed" }It would return immediately with a Task handle:
{ "resultType": "task", "taskId": "gh-actions-run-123456789", "status": "working" }GitHub MCP would own the wait, completing the Task when the run reaches a terminal state. Clients could use
tasks/getor task subscriptions instead of making the model poll Actions.This requires no webhook, tunnel, or inbound connectivity for a local server. On failure, the Task could optionally return failed jobs and relevant log tails using existing Actions capabilities.
Example prompts or workflows (for tools/toolsets only)
Additional context
GitHub MCP already has the Actions data plane. What is missing is the asynchronous waiting primitive.
Before MCP Tasks, client-driven polling was a reasonable workaround. Tasks now provide a protocol-native lifecycle for this operation.
Related: