Skip to main content
The GitHub connector lets your workflows talk to GitHub’s hosted MCP server, a remote MCP endpoint maintained by GitHub that exposes their full repository, issues, pull requests, and Actions surface.
Spojit does not curate the tool list; GitHub does. For the live set of tools and their parameters, see the GitHub MCP server documentation.
Spojit offers two connectors that point at the same GitHub MCP endpoint, differing only in how you authenticate:
ConnectorAuthBest for
GitHubPersonal Access TokenQuick setup, scripted/automated use, machine accounts
GitHub (OAuth)OAuth AppEnd-user flows where each member authorises with their own GitHub account

​
Connection setup: Personal Access Token

1

Create a fine-grained PAT

Go to github.com/settings/personal-access-tokens and click Generate new token. Pick a name, an expiry, and the repositories you want to grant access to.
2

Grant permissions

Under Repository permissions, grant the access your workflows need. Common picks:
  • Contents: Read (or Read and write to commit/push)
  • Issues: Read and write
  • Pull requests: Read and write
  • Actions: Read (for run status) or Read and write (to trigger runs)
Account permissions are usually not needed for repo-scoped workflows.
3

Add the connection in Spojit

Copy the token (it starts with github_pat_), go to Connections in Spojit, click Add Connection, select GitHub, and paste the token into the Personal Access Token field.

​
Connection setup: OAuth

1

Pick a scope preset

When you click Connect on the GitHub (OAuth) connector, Spojit asks which level of access to request:
  • Public repos only: public_repo + read:user. Read and write public repos. No access to private repositories.
  • All repositories: repo + read:user. Read and write public and private repos.
Pick the narrower scope unless you specifically need private repo access.
2

Authorise on GitHub

GitHub opens its authorisation page. Review the requested scopes and click Authorize. You’ll be redirected back to Spojit, and the new connection appears on the Connections page with status Connected.

​
Choosing between PAT and OAuth

  • Use a PAT when the integration is owned by your team (not a specific person) or when you want full control over expiry and revocation. PATs don’t depend on a user account staying active.
  • Use OAuth when each user should authorise with their own GitHub identity. Audit logs on GitHub then show the real actor for every API call.

​
Caveats

  • OAuth Apps don’t issue refresh tokens. Once an OAuth connection is made, the token stays valid until the user revokes it on GitHub and doesn’t rotate on a schedule.
  • GitHub OAuth scopes are coarse. There is no repo:read scope; the repo scope grants read and write across both public and private repos. If you need true read-only access on private repos, that isn’t expressible at the OAuth layer; you’d need to enforce it at the tool/policy layer or switch to a GitHub App with fine-grained permissions.
  • MCP endpoint is hosted by GitHub. Availability, rate limits, and the exact tool surface are determined by GitHub. Outages and breaking changes are upstream.

​
Tools

For the current list of tools and their parameters, see GitHub’s MCP server documentation.