GitHub MCP Server: How to Connect It to Spojit
Connect GitHub's hosted MCP server using the built-in Spojit connector, then use it in a workflow to summarise open pull requests.
What This Integration Does
GitHub publishes a remote MCP server, so instead of wiring up REST calls by hand your workflows get typed GitHub tools they can call: listing pull requests, reading issues, searching code, and more. Spojit ships a built-in GitHub connector pointed at that server, so you add it from the connector catalog with Add Connection and supply a credential. There is no custom server to configure and no OAuth app to register.
Once connected, you use it like any connector. A Connector node in Agent Mode lets the AI pick the right GitHub tools for a prompt; Direct Mode calls one specific tool. This tutorial connects GitHub, then builds a small workflow that produces a daily pull-request review digest for a repository. Run it manually to test, or put it on a Schedule trigger to receive the digest every morning.
Prerequisites
- A GitHub account with access to the repository you want to summarise.
- Permission to add connections in Spojit.
- For the token route, permission to create a fine-grained personal access token on the account or organization that owns the repository.
Step 1: Choose Which GitHub Connector to Use
Spojit offers two connectors that reach the same GitHub MCP endpoint and differ only in how you authenticate:
- GitHub: authenticates with a personal access token. Best for team-owned automation, machine accounts, and when you want direct control over expiry and revocation. A token does not depend on one person's account staying active.
- GitHub (OAuth): each member authorizes with their own GitHub account. Best when GitHub's audit log should show the real person behind every call.
This tutorial uses the token route. If you prefer OAuth, skip to Step 3 and choose GitHub (OAuth) instead, then pick a scope preset when Spojit asks: Public repos only grants public_repo and read:user, while All repositories grants repo and read:user, covering private repositories too. Pick the narrower one unless you need private repository access.
Step 2: Create a Fine-Grained Personal Access Token
In GitHub, go to Settings, Developer settings, Personal access tokens, Fine-grained tokens and click Generate new token. Give it a name, an expiry, and select the repositories you want Spojit to reach.
Under Repository permissions, grant only what your workflows need. For this digest:
- Pull requests: Read
- Contents: Read
- Issues: Read, if you also want issue context
Account permissions are not needed for repository-scoped work. Generate the token and copy it; it starts with github_pat_ and GitHub will not show it again.
Step 3: Add the Connection in Spojit
In Spojit, go to Connections and click Add Connection. Select GitHub from the catalog and paste the token into the Personal Access Token field. Save, and the connection appears under My Connections.
If you chose GitHub (OAuth) instead, click Connect, pick the scope preset, and approve on GitHub's authorization page. GitHub sends you back and the connection shows as Connected.
Step 4: Add GitHub to a Workflow
Open or create a workflow. Add a Connector node, open Select Connector, and choose GitHub from the catalog. Pick the connection you just created. Spojit discovers the available GitHub tools live, so the tool list reflects what the server currently offers. Set the node to Agent Mode so the AI can choose the right tools for the task.
Step 5: Write the Prompt
This is the automation: a standup-style digest of open pull requests. Paste this into the Prompt field, replacing owner/repo with your repository:
You have GitHub tools available. For the repository owner/repo:
1. List the open pull requests.
2. Write a concise standup digest grouped by author.
For each PR include: title, author, how long it has been open,
and whether it is a draft.
3. End with a "Needs review" list of any PR open more than 7 days,
so the team can prioritise.
Keep it short and skimmable.Optionally narrow Available Tools to just the pull-request and search tools so the agent stays focused and uses fewer tokens.
Step 6: Deliver the Digest
Add a Send Email node after the GitHub node, or a slack connector node to post it to a channel, and reference the previous step's output with {{ step1 }}. Then add a Schedule trigger set to a weekday morning so the digest arrives before standup.
Tips
- Grant the smallest set of repository permissions that does the job, and add write permissions only if a workflow needs to create issues or comment.
- Fine-grained tokens expire. Put a reminder in before the expiry date, or the workflow starts failing authentication with no other warning.
- Re-saving the connection refreshes the tool list, so tools GitHub adds later become available without recreating the connection.
- Spojit does not curate GitHub's tool list; GitHub does. The exact set of tools can change upstream.
Common Pitfalls
- Token scoped to the wrong repositories: a fine-grained token only reaches the repositories you selected when creating it. Adding a repository later means editing the token, not the Spojit connection.
- Wrong repository name: use the full
owner/repoform in the prompt. A bare repository name is ambiguous to the agent. - Expecting private data from a public-only OAuth grant: the Public repos only preset cannot see private repositories. Reconnect with All repositories if you need them.
- Assuming OAuth tokens rotate: GitHub OAuth Apps do not issue refresh tokens. The connection stays valid until the user revokes it on GitHub.
- Reaching for a custom server: GitHub is in the connector catalog, so adding it as a custom MCP server means registering an OAuth app you do not need.
Testing
Before running the full digest, confirm the connection works with a quick identity check. Add a Connector node on GitHub in Agent Mode with this prompt and run the workflow manually:
Use the GitHub tools to tell me who I am authenticated as:
my username, display name, and how many public repositories I have.If it returns the expected GitHub identity, the connection is working end to end. Then run the pull-request digest and inspect the output in the execution log. If a run fails, check that the repository name is correct and that the token or account you authorized can see it.