Skip to content
Tulina launches publicly tomorrowtoday
← Connecteurs

ToolsConnecteur

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.

Site officiel : github.com

Ce qu'il peut faire

1 lecture/4 écriture/1 envoi

  • 01
    Écriture

    Read repositories, branches, commits, tags and releases, and compare two refs

  • 02
    Écriture

    Read and write files, and open a branch for a change

  • 03
    Envoi

    Search, create, label, assign and comment on issues

  • 04
    Écriture

    Open, review and merge pull requests, and read the files they change

  • 05
    Écriture

    List Actions runs, jobs and logs, and dispatch a workflow

  • 06
    Lecture

    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:

  1. In GitHub, open Settings, then Developer settings, then Personal access tokens. A classic token needs the repo scope, plus read:org for teams and workflow for Actions. A fine-grained token needs the permissions and the list of repositories it applies to.
  2. 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/v3 for GitHub Enterprise Server.
  3. Add https://mcp.tulina.ai/mcp to 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 serverTulina's GitHub connector
Who runs itGitHub, hosted, or a local Docker imageTulina, with your token held in the vault
Sign-inOAuth or a personal access tokenA classic, fine-grained or app installation token
GitHub Enterprise ServerLocal server only; remote hosting is not offeredSupported through the API URL field
Repositories, issues, pull requestsYesgithub_repos, github_files, github_issues, github_pulls
Actions runs and logsYesgithub_actions, including dispatch, which is a dry run until told otherwise
Security findings, Dependabot alerts, discussions, notificationsListed among its usesNo tool for them
Next to your other toolsGitHubGitHub 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_pulls with merge writes to the target branch and has no one-click undo, and rerun can 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.

Pourquoi passer par Tulina

La connexion n'a jamais été le plus dur.

La plupart des outils publient désormais leur propre accès pour un modèle, et c'est tant mieux : c'est à cela que Tulina se connecte. Le plus dur, c'est de décider qui peut l'utiliser, ce qu'il a le droit de renvoyer, et ce que le modèle sait avant de demander.

  • Les clés restent au même endroit

    VousÉquipeOrganisation

    Connectez GitHub une fois. L'identifiant est chiffré dans un coffre, jamais conservé en clair, jamais collé dans une conversation ou un fichier. Chacun utilise sa propre clé s'il en a une, sinon celle de son équipe, puis celle de l'organisation : personne n'est bloqué, personne n'a plus d'accès qu'il n'en faut. Révoquez-la une fois, et tout ce qui en dépend s'arrête.

  • Ce qui sort est filtré avant de sortir

    champs retirésmasqués ou hachéspseudonymisés

    Les rôles décident qui peut atteindre GitHub. Au-delà, une politique posée sur le connecteur décide de ce qui revient. Les données sont minimisées à la source, pas après être arrivées dans un modèle.

  • Chaque appel est consigné

    quoiquiquand

    Chaque exécution est journalisée pour l'organisation. C'est ce qui rend une action automatisée vérifiable après coup, et c'est la première chose que demande une revue de sécurité.

  • L'exécution commence en connaissant l'entreprise

    vocabulairecomptes clésdécisions

    Une connexion directe donne un accès au modèle, pas la façon dont votre entreprise nomme les choses ni ce qui a été décidé le trimestre dernier. Tulina porte ce contexte d'un outil à l'autre, pour que la même demande sur GitHub renvoie quelque chose d'utilisable.

Processus qui utilisent GitHub

Aucun publié pour l'instant.

Découvrez Tulina en 30 minutes.

Réserver une démo