Connect GitHub Copilot to Claude: Manage seats, teams, and billing

If you need to connect GitHub Copilot to Claude to automate license provisioning, audit active seats, track enterprise billing, or manage coding agent policies, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's JSON-RPC tool calls and GitHub's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on /connect-github-copilot-to-chatgpt-analyze-usage-and-report-on-metrics/ or explore our broader architectural overview on /connect-github-copilot-to-ai-agents-automate-policies-and-security/.

Giving a Large Language Model (LLM) read and write access to your GitHub Copilot enterprise account is an engineering challenge. You have to handle OAuth 2.0 or Personal Access Token (PAT) lifecycles, map massive nested JSON schemas to MCP tool definitions, and deal with GitHub's strict API quotas. Every time GitHub releases a new public preview endpoint for Copilot metrics, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for GitHub Copilot, connect it natively to Claude Desktop, and execute complex seat management and billing workflows using natural language.

The Engineering Reality of the GitHub Copilot API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against GitHub's specific Copilot APIs is painful. You are not just building standard CRUD endpoints - you are interacting with enterprise billing mechanics, multi-level organization structures, and short-lived reporting URLs.

If you decide to build a custom MCP server for GitHub Copilot, here are the specific integration challenges you will face:

Ephemeral NDJSON Report URLs GitHub does not return massive usage reports in a standard synchronous JSON response. Endpoints like the enterprise user usage reports return a response containing temporary, signed download links pointing to NDJSON (Newline Delimited JSON) files. These signed URLs expire rapidly. An LLM cannot natively handle a multi-step operation where it receives a URL, initiates a separate HTTP GET outside its tool context, stream-parses an NDJSON file, and feeds it back into context. You must build an abstraction layer in your MCP server to fetch, parse, and summarize this telemetry before returning the context back to Claude.

Complex Bulk Assignment Constraints Managing seats in GitHub Copilot is rarely done one-by-one at scale. The API relies heavily on bulk operations, such as assigning seats via teams or passing arrays of usernames. If an LLM hallucinates a team name or passes a malformed array to a bulk assignment endpoint, the API will reject the payload. You must map these endpoints to rigidly defined JSON Schemas in your MCP tools to force Claude to format the payloads exactly as GitHub expects, handling partial success states if some users in an array are already assigned seats.

Strict Rate Limiting Without Implicit Backoff GitHub enforces strict API rate limits (typically 5,000 requests per hour for authenticated requests, though enterprise limits can vary). Truto does not retry, throttle, or apply backoff on rate limit errors automatically. When the GitHub API returns an HTTP 429 Too Many Requests error, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. Your MCP client architecture must be designed to intercept these errors, read the headers, and enforce a backoff strategy before re-prompting Claude to try again.

Creating the GitHub Copilot MCP Server

Truto dynamically generates MCP tools based on integration documentation and available resources - meaning a tool only appears if it is documented and AI-ready. Every MCP server is scoped to a single authenticated GitHub account.

You can create this server in two ways.

Method 1: Via the Truto UI

This is the fastest method for internal IT and DevOps teams looking to connect their own tools to Claude Desktop.

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Select your connected GitHub Copilot account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., restrict to read methods only, or set an expiration date).
6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the REST API

For platform engineers building automated workflows, you can programmatically generate MCP servers. This generates a secure token stored in Cloudflare KV for high-speed protocol routing.

curl -X POST https://api.truto.one/integrated-account/{account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Copilot FinOps Read-Only Server",
    "config": {
      "methods": ["read"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API validates that tools exist for your configuration, hashes the token securely, and returns the endpoint URL you will pass to Claude.

Connecting the MCP Server to Claude

Once you have your Truto MCP server URL, you must configure Claude to route tool execution requests to it.

Method A: Via the Claude UI (Web/Desktop)

If your organization uses Claude Team or Enterprise plans, or if you are using ChatGPT's custom connectors, you can add the server directly via the interface.

1. In Claude, navigate to Settings -> Integrations -> Add MCP Server (or in ChatGPT: Settings -> Connectors -> Add).
2. Name the integration (e.g., "GitHub Copilot Admin").
3. Paste the Truto MCP URL into the connection field.
4. Click Add. The client will automatically send an initialize JSON-RPC request to discover all available tools.

Method B: Via Manual Claude Desktop Configuration

If you are running Claude Desktop locally and prefer a declarative configuration, you can edit the claude_desktop_config.json file. Because Truto uses Server-Sent Events (SSE) for remote MCP connections, you will use the official @modelcontextprotocol/server-sse wrapper.

Add the following to your config file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "github_copilot": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_TRUTO_MCP_TOKEN"
      ]
    }
  }
}

Restart Claude Desktop. The application will immediately pull down the GitHub Copilot tool schemas.

GitHub Copilot Hero Tools

When Claude connects to the MCP server, it receives dynamically generated schemas that dictate exactly how to query the GitHub API. Here are the highest-leverage tools available for Copilot management.

list_all_git_hub_copilot_seats

Retrieves all Copilot seat assignments for an organization. This tool returns the created date, last activity date, plan type, and assignee details. It is essential for auditing inactive licenses.

"Review our GitHub Copilot seats for the 'acme-corp' org. Find any users who have not had any activity in the last 45 days and format their usernames into a markdown table."

create_a_git_hub_copilot_seat_team

Provisions Copilot seats in bulk by assigning them to specific GitHub teams. This is much safer and more scalable than assigning users individually, ensuring new engineering hires automatically get access.

"We just spun up a new platform engineering squad. Assign GitHub Copilot seats to the 'platform-infra-team' in the 'acme-corp' organization."

git_hub_copilot_seat_users_bulk_delete

Revokes Copilot access for specific organization members and cancels their billed seats. The tool accepts an array of usernames and requires the organization name.

"Remove Copilot access for jdoe, asmits, and bwayne from the 'acme-corp' org immediately as they are offboarding today."

list_all_git_hub_copilot_billing

Fetches high-level Copilot seat information and subscription settings for a GitHub organization. It returns the exact seat breakdown, IDE chat policy settings, and the plan type (Business vs Enterprise).

"Check the current GitHub Copilot billing status for 'acme-corp'. What is our total seat count, and do we have public code suggestions enabled?"

git_hub_copilot_enterprise_usage_reports_latest

Retrieves the most recent 28-day usage telemetry report for a Copilot Enterprise account. It returns the reporting window and signed NDJSON download links for deep metrics analysis.

"Pull the latest 28-day enterprise usage report for Copilot in 'acme-corp'. Grab the download links so we can parse the daily active user counts."

git_hub_copilot_coding_agent_permissions_bulk_update

Modifies the Copilot cloud agent policy for an organization. You can enforce whether the agent is enabled for all repositories, restricted to selected repositories, or completely disabled.

"Update the Copilot coding agent permissions for 'acme-corp' to only be enabled for selected repositories. We need to restrict access while we audit our legacy codebases."

For the complete inventory of available Copilot endpoints, schemas, and required parameters, review the GitHub Copilot integration page.

Workflows in Action

Let's look at how Claude uses these MCP tools to execute complex, multi-step workflows autonomously.

Scenario 1: IT Admin Cleaning Up Stale Licenses

Companies waste thousands of dollars on unused Copilot seats. An IT admin can prompt Claude to audit activity and revoke licenses for dormant users.

"Audit the GitHub Copilot seats for the 'acme-corp' organization. Identify any users who have not utilized Copilot in the last 60 days. Once identified, revoke their seats to free up billing, and give me a summary of who was removed."

How the agent executes this:

1. Claude calls list_all_git_hub_copilot_seats passing org: "acme-corp".
2. The agent parses the returned array of seat objects, comparing the last_activity_at timestamp against the current date.
3. It isolates a list of 14 usernames that exceed the 60-day dormancy threshold.
4. Claude calls git_hub_copilot_seat_users_bulk_delete, passing org: "acme-corp" and the array of 14 dormant usernames as selected_usernames.
5. The agent formats the API response confirming the cancellation and presents a summary table to the admin.

Scenario 2: Security Engineering Auditing Agent Policies

Security teams need to ensure that Copilot's cloud agent features are only active on approved repositories to prevent IP leakage.

"Check the current coding agent permissions for the 'acme-corp' organization. If the policy is set to allow all repositories, change it to 'selected repositories' only. Then, fetch the current list of allowed repositories."

How the agent executes this:

1. Claude calls list_all_git_hub_copilot_coding_agent_permissions to verify the current state.
2. It reads the response. If enabled_repositories is set to all, it proceeds to the next step.
3. Claude calls git_hub_copilot_coding_agent_permissions_bulk_update, passing the required payload to set the policy to selected.
4. Once confirmed, Claude calls list_all_git_hub_copilot_coding_agent_repositories to pull the active list of approved repo IDs and names, returning the final status to the security engineer.

sequenceDiagram
    participant User as Security Engineer
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant GitHub as GitHub API

    User->>Claude: "Check agent permissions..."
    Claude->>Truto: Call tool: list_all_git_hub_copilot_coding_agent_permissions
    Truto->>GitHub: GET /orgs/{org}/copilot/billing/custom_models
    GitHub-->>Truto: Return policy: "all"
    Truto-->>Claude: Return policy state
    Claude->>Truto: Call tool: git_hub_copilot_coding_agent_permissions_bulk_update
    Truto->>GitHub: PUT /orgs/{org}/copilot/billing/custom_models
    GitHub-->>Truto: 204 No Content
    Truto-->>Claude: Success
    Claude->>Truto: Call tool: list_all_git_hub_copilot_coding_agent_repositories
    Truto->>GitHub: GET /orgs/{org}/copilot/custom_models/repositories
    GitHub-->>Truto: Return array of allowed repos
    Truto-->>Claude: Tool result (JSON)
    Claude-->>User: Present updated policy and repo list

Security and Access Control

Giving an AI agent administrative access to your GitHub Copilot enterprise account requires strict guardrails. Truto's MCP architecture provides several layers of access control at the token generation stage:

• Method Filtering: You can configure an MCP server with methods: ["read"] to ensure Claude can only audit seats and run reports, stripping out tools like git_hub_copilot_seat_users_bulk_delete entirely.
• Tag Filtering: Restrict the LLM's access to specific resource groups by passing tags: ["billing"], ensuring the model only sees tools related to financial data and not repository source code.
• API Token Authentication: By setting require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The client must also pass a valid Truto API token in the header, adding a mandatory second layer of identity verification.
• Automatic Expiration: Use the expires_at field to create temporary, short-lived MCP servers (e.g., giving a contractor AI read access to Copilot billing for exactly 24 hours, after which Cloudflare KV automatically drops the credentials).

Moving from Click-Ops to Chat-Ops

Managing GitHub Copilot across a large engineering organization usually requires writing Python scripts, juggling PATs, and manually parsing NDJSON files to figure out who is actually using their license. By wrapping the GitHub Copilot API in a managed MCP server, you eliminate the integration boilerplate.

You give Claude explicit, schema-driven access to manage seats, assign teams, and audit enterprise usage. With robust security controls like read-only method filtering and standardized rate limit handling, you can safely hand off routine license provisioning to AI agents without compromising your organization's administrative perimeter.