ToolsConnector
GitHub
Read repositories, triage issues and pull requests, watch Actions runs and open branches from Claude or ChatGPT via the Tulina MCP server, on your own token.
Official site: github.com
What it can do
1 read/4 write/1 send
- 01Write
Read repositories, branches, commits, tags and releases, and compare two refs
- 02Write
Read and write files, and open a branch for a change
- 03Send
Search, create, label, assign and comment on issues
- 04Write
Open, review and merge pull requests, and read the files they change
- 05Write
List Actions runs, jobs and logs, and dispatch a workflow
- 06Read
Search code, repositories, issues and commits with GitHub's own syntax
GitHub holds the part of a company's work that the CRM never sees: what shipped, what is stuck in review and which bug a customer's ticket is about. The Tulina connector lets an agent read and act on it with the same token a person would use, then carry the result to Slack, Linear or the inbox in the same conversation. Every commit, comment and merge is attributed to the holder of the token.
What is MCP in GitHub?
It is GitHub's official MCP server, which connects AI tools to GitHub so an
agent can read repositories and code files, manage issues and pull requests,
and follow workflow runs. GitHub's repository for the server describes two
ways to run it: a remote server hosted by GitHub at
https://api.githubcopilot.com/mcp/, signed in with OAuth or a personal
access token, and a local server run in Docker. Tulina's connector is a
different route to the same platform, through the GitHub API and a token you
hold.
Is GitHub MCP useful?
For a revenue or product team it is useful when GitHub is one step in a longer piece of work. GitHub's own list of uses covers repository browsing, issue and pull request automation, workflow monitoring, code analysis and team activity. The Tulina connector covers the first three directly: an agent can see which pull requests are waiting, read the diff, check why a build failed, and file the ticket that follows. Anything that needs the model to hold a repository open all day is better served by GitHub's own server in an editor.
How do you connect GitHub to Claude and ChatGPT?
Through Tulina's own MCP server, in three steps:
- In GitHub, open Settings, then Developer settings, then Personal access
tokens. A classic token needs the
reposcope, plusread:orgfor teams andworkflowfor Actions. A fine-grained token needs the permissions and the list of repositories it applies to. - Paste it into the GitHub card in Tulina. It is stored in the vault and
never shown to the model. Leave the API URL empty for github.com, or enter
https://<your-host>/api/v3for GitHub Enterprise Server. - Add
https://mcp.tulina.ai/mcpto Claude or ChatGPT and sign in with your Tulina account. The MCP page has the same link.
A repository missing from a fine-grained token's list answers "not found", because GitHub returns 404 on a private resource a token may not see.
GitHub's own MCP server and Tulina's GitHub connector
| GitHub's MCP server | Tulina's GitHub connector | |
|---|---|---|
| Who runs it | GitHub, hosted, or a local Docker image | Tulina, with your token held in the vault |
| Sign-in | OAuth or a personal access token | A classic, fine-grained or app installation token |
| GitHub Enterprise Server | Local server only; remote hosting is not offered | Supported through the API URL field |
| Repositories, issues, pull requests | Yes | github_repos, github_files, github_issues, github_pulls |
| Actions runs and logs | Yes | github_actions, including dispatch, which is a dry run until told otherwise |
| Security findings, Dependabot alerts, discussions, notifications | Listed among its uses | No tool for them |
| Next to your other tools | GitHub | GitHub plus the ticketing, chat and CRM connectors |
If the work lives in an editor and touches only GitHub, GitHub's own server is the shorter path. Tulina earns its place when a merged pull request should update Linear and tell Slack without anyone copying a link.
What you can ask it
"Which pull requests in acme/api have waited for review more than three days?" The agent searches open pull requests, reads the reviews on each, and returns a short list with the age and the requested reviewers.
"Why did the last deploy workflow fail?" The agent lists the recent runs, takes the failed one, reads its jobs and fetches the log of the job that failed, then explains the error in a sentence.
"Fix the typo in the README and open a pull request." The agent creates a branch, writes the file on that branch and opens the pull request with the branch as its head. Nothing reaches the default branch until a person merges.
What runs on its own: any of these can be scheduled, for instance the review queue every morning posted to Slack. A merged pull request can also update the matching ticket in Linear and say so in the team channel.
What the GitHub connector can't do
- It can read only what the token can read. A private repository the token cannot see answers 404, and so does one outside a fine-grained token's list.
- Pages are capped at 100 rows, and search stops at 1,000 results whatever total GitHub announces. Code search covers the default branch only, skips files over 384 KB and needs a real search term.
- Large pull requests come back incomplete: the file list stops at 3,000 files and the commit list at 250.
github_pullswithmergewrites to the target branch and has no one-click undo, andreruncan bill Actions minutes. Treat both as actions that need a person's yes.- A review without an event stays pending and notifies nobody.
- There is no tool for security alerts, Dependabot, discussions or notifications, and a shared key does not exist: every action carries the identity of its token.
Why through Tulina
The connection was never the hard part.
Most systems now publish their own way for a model to reach them, and that is good: it is what Tulina connects to. The hard part is deciding who may use it, what it is allowed to return, and what the model knows before it asks.
The keys stay in one place
YouTeamOrganisation
Connect GitHub once. The credential is encrypted in a vault, never held in clear, and never pasted into a chat or a workflow file. A person uses their own key where they have one, their team's where they do not, the organisation's after that, so nobody is blocked and nobody holds more access than they need. Revoke it once and everything running on it stops.
What leaves is filtered before it leaves
fields droppedmasked or hashedpseudonymised
Roles decide who can reach GitHub at all. Beyond that, a policy on the connector itself decides what comes back. The data is minimised at the source rather than after it has already reached a model.
Every call is on the record
whatwhowhen
Runs are logged for the organisation. That is what makes an automated action reviewable after the fact, and it is what a security review asks for first.
The run starts knowing your company
namingkey accountsdecisions
A direct connection gives a model access. It does not tell it how your company names things, which accounts matter, or what was decided last quarter. Tulina carries that across every tool, so the same request against GitHub returns something usable instead of something generic.
Processes that run on GitHub
None published yet.