GitHub MCP Integration

Weldable's GitHub MCP integration gives your AI agents direct access to repositories, issues, pull requests, commits, releases, and more. With 51 actions covering the full GitHub API surface, your agent can manage your development workflow through plain English. No scripts, no curl commands, no token management.

GitHub has its own official MCP server, but it requires local setup and configuration per client. Weldable handles OAuth, token refresh, and multi-integration orchestration in one place. Connect once and your agent works across GitHub, Slack, Google Docs, and every other Weldable integration simultaneously.

Use cases

Automated release notes from commit history

Your agent compares two tags using compare_commits, collects every commit message and PR reference between them, groups changes by type (fix, feature, chore), and drafts release notes. Then it calls create_release to publish the version with those notes attached. Pair this with Slack to post the changelog to #releases automatically.

PR review triage and tracking

Ask your agent to list open pull requests filtered by label or reviewer status using list_pull_requests. It reads the changed files with list_pr_files, checks which PRs have been waiting longest, and posts a daily summary. For teams with review bottlenecks, the agent can identify PRs with no reviews via list_pr_reviews and ping the right people on Slack.

Issue intake and labeling

When bugs come in from support channels, your agent creates GitHub issues with create_issue, applies the right labels with add_labels_to_issue, and assigns them based on which area of the codebase is affected. It can check the repository's existing labels with list_labels first to stay consistent. Combine with Gmail to turn email reports into tracked issues.

Cross-repo project visibility

Your agent can call list_user_repos to find all repositories in your account, then list_repo_issues across multiple repos to build a unified view of open work. Use list_commits with date filters to see what shipped this week across projects. This turns your agent into a project dashboard that answers questions like "what landed in the API repo since Monday?"

CI/CD monitoring and re-runs

Use list_workflow_runs to check the status of your GitHub Actions pipelines. Your agent can filter by branch or status to find failed runs, pull the failure details, and trigger a re-run with trigger_workflow_dispatch. Useful for flaky tests or infrastructure hiccups where a retry is the right fix.

How it works

Connect your GitHub account through a one-click OAuth flow. Weldable requests repo, read:org, read:user, workflow, and gist scopes, giving your agent access to repositories, organizations, CI/CD, and gists. Tokens refresh automatically in the background.

Once connected, talk to your agent in plain language. Say "show me open PRs in my-org/api-server" and Weldable matches your intent to the list_pull_requests action, fills in the owner and repo parameters, and calls the GitHub API. Your agent gets structured JSON back, which it can summarize, filter, or feed into the next action.

Actions chain naturally. Your agent can read a PR's changed files, check if tests passed, post a review comment, and then merge, all in a single conversation turn. Because Weldable connects to multiple services, your agent can also cross boundaries: read a GitHub issue, draft a response in Google Docs, and notify the team on Slack.

Tips

Use GitHub's search query syntax for precise results. The five search actions (search_repos, search_code, search_issues, search_users, search_commits) accept the same qualifier syntax as github.com. Tell your agent "search issues with label:bug and state:open in my-org/backend" and it builds the right query string. Qualifiers like language:, repo:, and is:pr work too.

Filter commits by path and date range. The list_commits action accepts path, since, and until parameters. Instead of fetching everything, ask for "commits to src/api/ in the last week" and get exactly what you need. This keeps responses fast and relevant.

Use compare_commits for branch diffs, not just releases. The basehead parameter takes any two refs in base...head format. Compare your feature branch against main before opening a PR, or check what changed between two arbitrary commits. Your agent can summarize the diff in plain English.

Draft releases before publishing. The create_release action supports a draft parameter. Have your agent create a draft release with auto-generated notes, review it yourself, then publish. This keeps humans in the loop for public-facing releases.

Combine with Slack for team-facing automation. GitHub data is most useful when it reaches the right people at the right time. Have your agent post PR summaries to project channels, notify authors when their CI fails, or drop a weekly contributor report in #engineering.

Be specific with owner and repo. Most actions require owner and repo as separate parameters. Tell your agent "in facebook/react" or "in my-org/backend" and it parses those correctly. If you only say "the repo," your agent will ask for clarification.