How to set up the GitHub MCP server

GitHub hosts source code, pull requests, issues, and software-delivery workflows. Use the hosted server's OAuth flow for a user-delegated connection, or a fine-grained personal access token for a dedicated automation identity.

This is the vendor-side setup guide for GitHub's hosted MCP server. It covers the work that must be complete in GitHub before any MCP client can connect. The GitHub agent template is a separate deployment step; it provisions the Dome workspace, agent, model, tools, and rules after this GitHub configuration is ready.

Choose a connection method

GitHub's hosted read-only endpoint is https://api.githubcopilot.com/mcp/readonly. GitHub supports OAuth by default and a personal access token (PAT) as a manual alternative. The right option depends on whether access should be delegated per user or held by a dedicated automation identity.

Consult GitHub's MCP server setup guide before configuring either method.

Recommended: OAuth

Choose OAuth for a per-user connection. GitHub can start a one-click OAuth flow from supported MCP clients, but a Dome connection needs a manually registered GitHub OAuth app because the hosted MCP server does not expose Dynamic Client Registration.

Create the OAuth app

1. Open GitHub developer settings, select OAuth Apps, then select New OAuth App. GitHub's OAuth-app creation reference describes each field.

2. Give the app a recognizable name, such as Dome MCP test, and enter your organization's homepage URL.

3. Enter this exact Authorization callback URL:

   text

   https://api.domesystems.ai/oauth/callback

4. Create the app. Copy its Client ID, then generate and copy a Client secret. Store the secret only in Dome's template-import prompt or another secret manager—never in source control.

5. Import the Dome GitHub template with those two values, then select Authorize on the GitHub connection and sign in as the dedicated test user. For the read-only endpoint, the template requests public_repo and read:org; approve only those scopes for a public-repository test.

GitHub OAuth Apps do not provide a read-only private-repository scope. Do not grant repo merely to make a read-only workflow work; begin with a public test repository. Use a fine-grained PAT when private repository read access is required.

Alternative: Fine-grained PAT

Choose a fine-grained PAT for a shared, service-style connection. Create it under the intended test identity, set its resource owner deliberately, select only the repositories the MCP server must reach, and grant the smallest read permissions required. Do not use a classic PAT or a broad personal token as a shortcut.

GitHub's MCP server setup guide documents both flows and the endpoint. A PAT is sent as Authorization: Bearer <token>; store that value only in the MCP client's secret storage, never in a prompt or runtime environment.

• Open the vendor's credential documentation as the dedicated least-privileged identity.
• Create a named credential for the intended test workspace, project, organization, or account—never reuse an owner or administrator credential.
• Select the minimum scopes, repositories, projects, or resources the MCP server needs; begin read-only whenever the product supports it.
• Copy the secret once into the MCP client's secret store, record its owner and rotation date, then test both an allowed record and a denied boundary.

Complete the organization prerequisites

Before opening the authorization flow, ask the GitHub organization or enterprise administrator to check these controls:

• The test user or automation identity can see only the intended test organization and repositories.
• Fine-grained PAT policy permits the selected organization and repositories, if you chose a PAT.
• Enterprise Managed Users are allowed to create and use PATs, if applicable. GitHub disables PATs for Enterprise Managed Users by default unless an enterprise administrator enables them.
• OAuth-app policy allows the MCP host's OAuth flow, if you chose OAuth. Organization policy can restrict approved OAuth apps and scopes.

Use one non-production repository with a known issue and pull request for the first verification. It makes an authorization failure distinguishable from an empty repository or missing resource.

Create a least-privileged credential

For OAuth, start the sign-in flow from the MCP client and approve only the access requested for the intended read-only use case. Do not approve repository administration, workflow changes, package management, or organization writes for a search-and-summary workflow. For a PAT, GitHub supports a fine-grained PAT as the documented static-credential alternative; do not use a classic PAT.

For a fine-grained PAT, create a short-lived token for the test identity. Limit repository selection to the test repository or repositories, choose read-only permissions, record its expiration, and wait for any organization approval required by policy. Keep the raw token in a secret manager; never paste it into source control, a prompt, or a .env file.

Configure the GitHub server in your MCP client

Configure the remote server with the endpoint below. OAuth-capable clients should start their authorization flow without a manually supplied token. For a PAT connection, add the Authorization header shown below.

https://api.githubcopilot.com/mcp/readonlyAuthorization: Bearer <fine-grained-PAT>

GitHub's documentation calls this a remote HTTP MCP server. The server's available tools and access are still constrained by the authenticated identity and organization policy.

Verify GitHub MCP

Do this before you use the server for automation:

• Complete authorization and confirm the MCP client discovers GitHub tools.
• Ask for the title of a known issue or pull request in the test repository.
• Ask for a repository outside the selected scope. It should be unavailable or denied.
• Confirm no write tool or permission was granted for the read-only setup.
• Record the identity, organization policy decision, token expiration (if used), endpoint, and successful test in your change record.

A successful sign-in alone is not proof of the intended boundary. The positive and negative repository checks are what show that the credential and GitHub policy are behaving as designed.

Troubleshooting

If OAuth is blocked, check the organization or enterprise OAuth-app policy before retrying. If a PAT is rejected, verify its expiration, selected resource owner, repository selection, permissions, and any pending organization approval. If the server connects but cannot find a known resource, test the same resource as the intended GitHub identity and then re-check repository scope. Rotate a token exposed outside the connection immediately.

Next steps

Deploy the GitHub agent template to create a governed agent in Dome that can work with the approved repositories and organization data, with the template's included model, tools, and rules.