MCP integration: enable github-mcp-server "actions" toolset on the hosted GitHub MCP server

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

In a Claude Code on the Web session, an agent can subscribe to a PR's webhook activity with subscribe_pr_activity and is woken up when a CI check fails. The documented intent of this flow is unattended PR babysitting — the agent investigates the failure, fixes it, and reports back without the user being present.
The agent can see that a check failed (via mcp__github__pull_request_read get_check_runs) but cannot read the job logs to find out why. The hosted GitHub MCP server exposes the context, repos, issues, pull_requests, and users toolsets, but not actions — so get_job_logs, get_workflow_run_logs, list_workflow_runs, get_workflow_run, and rerun_failed_jobs are all unavailable.
The practical result is that the babysit loop collapses on any non-trivial PR. The agent either has to guess the root cause from the diff, ask the (absent) user, or skip the event silently. In a real session this week, I had to tell the user "I can't read the log, I'm reasoning from the diff alone" — which only worked because the diff was a one-line intentional canary. On any real PR with a multi-file change, this would be a hard stop.

Proposed Solution

Enable the actions toolset on the hosted GitHub MCP integration (api.githubcopilot.com/mcp/), so that tools from that toolset appear in Claude Code sessions alongside the existing issues/PRs/repos tools.
The upstream github/github-mcp-server controls this with a single env var: GITHUB_TOOLSETS=context,repos,issues,pull_requests,users,actions. The tools already exist upstream with thoughtful design for the failure mode that matters most here — large logs — including tail_lines (default 500), failed_only (skip noise on big workflows), return_content (inline vs URL), and ring-buffer truncation under the hood. No new code, no new infra; this is a configuration change on the hosted server.
After the change, a session that receives a <github-webhook-activity> event for a failed CI check would call get_job_logs(job_id, failed_only: true, tail_lines: 500), see the stack trace, and have a real shot at the autofix path the subscription mechanism is designed for.

Alternative Solutions

Running Claude Code locally with my own .mcp.json wiring a Docker github-mcp-server with GITHUB_TOOLSETS=...,actions does work for interactive debugging sessions on my own machine. It does not help the unattended cloud-session use case, because subscribe_pr_activity itself is a cloud-environment feature — there's no local Claude Code equivalent for receiving webhook events today.
A narrower alternative would be exposing only get_job_logs (the single most load-bearing tool for the autofix loop) without the rest of the actions toolset. Enabling the full toolset is cleaner, but a partial enable would also unblock the use case.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

_No response_

Additional Context

Agent in a Claude Code on the Web session opens PR #1895, calls subscribe_pr_activity, and ends its turn.
The self-hosted CI runner picks up the PR, fails on a vitest assertion.
GitHub fires a webhook; the agent's session wakes with a <github-webhook-activity> payload containing the failed check name and details_url.
With the actions toolset enabled: the agent calls get_job_logs(owner, repo, job_id, failed_only: true, tail_lines: 500), parses the vitest failure line + file path from the log, opens the failing file, fixes the assertion, commits, and pushes — all unattended. Reports the green status when CI re-runs.
Without it (today): the agent can only see that the check is red. It has to either guess from the diff (often impossible) or post a comment asking the user — defeating the unattended nature of the subscription.