/ 디렉터리 / 플레이그라운드 / GitHub
← 모든 서버 ↗ GitHub
● 공식 github 🔑 본인 키 필요

GitHub

제작: github · github/github-mcp-server

Claude에 GitHub 전체 접근권 부여 — issues, PRs, 코드 검색, 파일 편집 — 채팅창을 떠나지 않고 모두 가능합니다.

GitHub 공식 MCP 서버입니다. GitHub REST 또는 GraphQL API로 할 수 있는 모든 작업을 AI 에이전트도 수행할 수 있습니다: issues 분류, PRs 검토, 조직 코드 검색, commit 초안 작성 등. 읽기 전용 모드가 지원되며 첫 실행에 권장됩니다.

▶ 데모 보기 📦 설치 💡 사용 사례

왜 쓰나요

핵심 기능

라이브 데모

실제 사용 모습

github.replay ▶ 준비됨
0/0

설치

클라이언트 선택

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config 열기. 저장 후 앱 재시작.

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Cursor는 Claude Desktop과 동일한 mcpServers 스키마 사용. 프로젝트 설정이 전역보다 우선.

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Cline 사이드바의 MCP Servers 아이콘 클릭 후 "Edit Configuration" 선택.

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Claude Desktop과 같은 형식. Windsurf 재시작 후 적용.

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "github",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  ]
}

Continue는 맵이 아닌 서버 오브젝트 배열 사용.

~/.config/zed/settings.json
{
  "context_servers": {
    "github": {
      "command": {
        "path": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ]
      }
    }
  }
}

context_servers에 추가. 저장 시 Zed가 핫 리로드.

claude mcp add github -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

한 줄 명령. claude mcp list로 확인, claude mcp remove로 제거.

사용 사례

실전 활용법: GitHub

좋은 첫 번째 issue를 찾아 한 시간에 수정사항 배포하기

👤 마찰 없는 첫 번째 PR을 찾는 오픈소스 기여자 ⏱ ~60 min beginner

언제 쓸까: 프로젝트에 기여하고 싶지만 어디서 시작해야 할지 모를 때. 유지관리자의 CONTRIBUTING.md가 너무 일반적이어서 도움이 안 될 때.

사전 조건
  • GitHub PAT with repo:read and issues:read — github.com/settings/tokens — 세분화된 토큰으로 기여하려는 저장소에 범위 지정
  • filesystem MCP도 설치됨 — Claude가 저장소를 로컬에서 복제하고 읽어 실제 수정사항을 작성할 수 있게 함
흐름
  1. good first issue로 표시되고 댓글 없는 issues를 단순성으로 정렬해 찾도록 요청
    modelcontextprotocol/servers에서 'good first issue' 레이블이 붙고 담당자 없으며 댓글 없는 열린 issues를 찾기. 고치기 가장 쉬워 보이는 것을 선택해 이유 설명하기.✓ 복사됨
    → Claude가 각각에 대해 한 줄짜리 난이도 평가를 포함한 3-5개 후보 반환
  2. Claude에게 issue 본문과 연결된 코드 가져오도록 요청
    #<num>의 전체 issue 본문을 가져오고 언급한 파일 읽기. 실제로 일어나야 할 변경사항 설명하기.✓ 복사됨
    → 구체적인 diff 의도, issue의 단순 재진술 아님
  3. filesystem MCP로 편집을 진행한 후 GitHub MCP로 PR 초안 작성
    변경사항 적용, 유지관리자에게 감사하고 3문장으로 수정사항을 설명하는 PR 설명 작성하기.✓ 복사됨
    → PR이 열리고 링크가 반환됨

결과: 프로젝트 스타일을 존중하고 issue를 참조하며 당일에 병합할 수 있을 만큼 작은 열린 PR.

함정
  • Claude가 2년간 방치되었던 'good first issue'를 선택하는데, 이는 아무도 수정사항에 동의할 수 없었기 때문 — 지난 90일 동안 유지관리자의 새로운 댓글 없음을 필터로 추가하기
  • PR 본문이 일반적인 AI 스타일 — Claude에게 먼저 프로젝트의 최근 병합된 PR 3개의 톤을 따라하도록 지시하기
함께 쓰기: filesystem · git

팀을 위한 주간 PR 요약 생성

👤 엔지니어링 매니저, 기술 리더 ⏱ ~10 min intermediate

언제 쓸까: 매주 월요일 아침 40개의 PR 알림을 클릭하지 않고 싶을 때.

사전 조건
  • PAT scoped to your team's repos with pull_requests:read — 세분화된 토큰 사용, 절대 기존 '모든 저장소' 토큰 사용하지 않기
흐름
  1. 지난주 병합된 PRs의 diff 크기와 함께 요청
    org/repo에 지난 월요일부터 오늘까지 병합된 모든 PRs를 나열하기. 작성자, +/- 줄 수, 한 줄 요약 포함.✓ 복사됨
    → 구체적인 델타를 포함한 10-30행 테이블
  2. 작성자와 주제별로 그룹화
    영역별로 그룹화하기(auth, payments, frontend, infra...) 그리고 revert나 hotfix로 보이는 것 표시하기.✓ 복사됨
    → 주제별 클러스터링된 섹션
  3. Slack 준비 완료 요약 초안 작성
    이제 주간 요약 Slack 게시물 작성하기 — 큰 성과 축하, 위험한 변경사항 지적, 배포한 사람 이름 표시.✓ 복사됨
    → @mentions와 이모지가 있는 마크다운, 붙여넣기 준비 완료

결과: 월요일 아침에 실제로 읽고 싶은 5개 항목 요약.

함정
  • 조직에 저장소가 많으면 속도 제한에 도달 — 한 번에 한 저장소로 필터링하거나 GitHub App 토큰으로 업그레이드(시간당 15k req vs 5k)
함께 쓰기: linear · sentry

코드베이스가 deprecated API를 사용하는 모든 위치 찾기

👤 마이그레이션을 계획 중인 백엔드 엔지니어 ⏱ ~30 min intermediate

언제 쓸까: 내부 클래스/함수를 deprecated하려고 하는데, 발표하기 전에 누가 사용하는지 알아야 할 때.

사전 조건
  • PAT with repo:read for all repos in your org — 조직 전체 접근을 위해 GitHub App 사용 — 저장소별 PATs를 관리하는 것보다 쉬움
흐름
  1. 조직 전체에서 코드 검색 사용
    전체 acme-corp 조직에서 LegacyAuth 클래스의 모든 사용 검색하기. 저장소별로 그룹화한 파일 경로 반환.✓ 복사됨
    → 저장소 및 파일 목록, 줄 번호 포함
  2. 각 일치항목에 대해 컨텍스트 가져오기
    각 일치항목에 대해 사용 주변 5줄 가져오고, 실제 호출인지 아니면 댓글/import인지 알려주기.✓ 복사됨
    → 실제 호출을 노이즈와 구별하는 필터링된 목록
  3. 마이그레이션 추적 issue 생성
    acme-corp/platform에서 'Migrate off LegacyAuth' 제목의 추적 issue 생성, 모든 실제 호출 위치와 각 저장소를 소유한 팀의 체크리스트 포함.✓ 복사됨
    → 포괄적인 체크리스트가 있는 issue 생성됨

결과: 플랫폼 팀이 마이그레이션을 진행하는 데 사용할 수 있는 단일 신뢰할 수 있는 추적 issue.

함정
  • 코드 검색은 쿼리당 1000개 결과 상한선 있음 — 상한에 도달하면 언어나 경로로 좁히기: LegacyAuth language:python 또는 저장소 접두사로 쿼리 분할
  • GitHub는 기본 브랜치만 인덱싱 — 기능 브랜치의 사용을 찾지 못함 — 복제된 저장소에서 로컬 grep으로 보충
함께 쓰기: filesystem

승인하기 전에 까다로운 PR에 대한 두 번째 의견 받기

👤 전문 분야 밖의 PR을 접하는 코드 리뷰어 ⏱ ~15 min intermediate

언제 쓸까: 자신이 잘 모르는 코드를 건드리는 PR의 담당 리뷰어인데, 단순 형식적인 승인을 하고 싶지 않을 때.

흐름
  1. PR diff와 설명 가져오기
    org/repo에서 PR #<num> 가져오기 — diff와 설명 제공. 작성자가 이것이 무엇을 한다고 주���하는가?✓ 복사됨
    → 의도의 명확한 재진술
  2. 아키텍처 분석 요청
    이제 이 PR이 건드리는 기존 파일들을 보기. 변경사항이 기존 패턴에 맞는가, 아니면 새로운 패턴을 도입하는가? 새로운 경우, 새로운 패턴이 정당한가?✓ 복사됨
    → 구체적인 지적, 일반적인 칭찬 아님
  3. 위험 요소 조사
    이 diff 중 6개월 후 프로덕션에서 깨질 가능성이 가장 높은 부분은 어디인가? 구체적으로 — 줄을 지적하기.✓ 복사됨
    → 구체적인 줄 수준 우려, '더 많은 테스트 추가'가 아님

결과: PR에 게시할 수 있는 3개의 구체적이고 실행 가능한 댓글 — 리뷰를 훑어보는 것보다 훨씬 나아지게 함.

함정
  • Claude가 무조건 수용하는 기계가 되어 모든 것을 칭찬함 — 명시적으로 '이 회사의 senior engineer는 무엇에 반박할까?'라고 묻기 — 적대적 구성이 도움이 됨
함께 쓰기: filesystem

리뷰에서 부패하는 PRs 식별 및 해제

👤 엔지니어링 리더, 저장소 유지관리자 ⏱ ~20 min beginner

언제 쓸까: 한 번의 스프린트마다, PRs가 아무도 모르게 오래되고 있다고 의심할 때.

흐름
  1. 5일 이상 열려있고 최근 활동 없는 PRs 목록화
    org/repo에서 마지막 업데이트가 5일 이상 된 열린 PRs 찾기. 각각에 대해 작성자, 담당 리뷰어, 지연 이유(마지막 댓글 확인) 알려주기.✓ 복사됨
    → PR당 진단이 있는 테이블
  2. 지연 분류
    다음으로 그룹화하기: '리뷰어 대기 중', '작성자 대기 중', 'CI 대기 중', '결정 대기 중'. 어느 것인지 구체적으로 설명.✓ 복사됨
    → 각각 구체적인 PRs이 있는 4개 범주
  3. 재촉 초안 작성
    '리뷰어 대기 중' 버킷에 대해 각각에 대한 정중한 재촉 댓글 초안 작성하기. 리뷰어가 작성자와 동료인지 선배인지에 따라 톤 다르게.✓ 복사됨
    → PR당 게시할 준비가 된 댓글 텍스트

결과: 15분에 해제할 수 있는 짧은 PRs 목록, PR당 구체적인 조치 포함.

함정
  • 자동 댓글 게시가 스팸처럼 느껴짐 — Claude에게 댓글 초안 작성하게 하되 직접 게시하기 — 인간이 루프에 있게 유지
함께 쓰기: linear

조합

다른 MCP와 조합해 10배 효율

github + sentry

Sentry가 새 오류를 노출 → GitHub MCP가 릴리스 태그를 통해 이를 도입한 commit 찾음 → 한 채팅에서 모두 hotfix PR 초안 작성

Sentry에 새 오류 발생 — issue WEB-3a91. main에서 이를 도입한 commit 찾기(릴리스 태그와 교차 참조), 그 후 가능한 가장 작은 revert PR 초안 작성.✓ 복사됨
github + linear

GitHub 버그 보고서에서 올바른 레이블 및 우선순위가 있는 Linear issues 자동 생성

이번 주 octocat/api 저장소에서 'bug' 레이블로 열린 모든 issue에 대해, BACKEND 팀에서 우선순위 Medium인 매칭 Linear issue 생성하기.✓ 복사됨
github + filesystem + git

엔드투엔드 기여: 저장소를 로컬에서 복제, 변경사항 적용, 브랜치 push, PR 열기 — 채팅을 떠나지 않음

acme/widgets를 로컬에서 복제, src/utils/format.ts:42의 오타 수정, 새 브랜치로 push, PR 열기.✓ 복사됨

도구

이 MCP가 노출하는 것

도구입력언제 호출비용
search_issues owner: str, repo: str, labels?: str[], state?: str 레이블, 상태, 담당자 또는 활동별로 issues를 찾으려고 할 때 1개 GitHub API 호출
get_issue owner: str, repo: str, issue_number: int search_issues 후, 전체 대화가 필요할 때 1개 API 호출
create_issue owner, repo, title, body, labels?, assignees? 새로운 issue를 제출 — 사용자가 실제로 이를 원하는지 확인 1개 API 호출 (쓰기)
list_pull_requests owner, repo, state?, sort?, base?, head? 상태/브랜치/작성자별로 PRs 찾기 1개 API 호출
get_pull_request owner, repo, pull_number 특정 PR의 diff와 메타데이터 읽기 1개 API 호출
merge_pull_request owner, repo, pull_number, merge_method? 명시적으로 지시받을 때만 — 먼저 드라이런 논의 사용 1개 API 호출 (쓰기, 되돌릴 수 없음)
search_code q: str, sort? 조직 전체에서 기호 사용 찾기 1개 API 호출 (낮은 속도 제한: 분당 30개)
get_file_contents owner, repo, path, ref? 복제하지 않고 저장소에서 단일 파일 읽기 1개 API 호출
create_or_update_file owner, repo, path, message, content, sha? 일회성 파일 편집; 다중 파일 변경의 경우 브랜치 + PR 사용 1개 API 호출 (쓰기)
list_commits owner, repo, sha?, path? 파일 또는 브랜치 이력 감사 1개 API 호출

비용 및 제한

운영 비용

API 쿼터
Personal PAT: 시간당 5,000개 요청. GitHub App: 시간당 15,000개. 코드 검색: personal은 분당 30개, 별도.
호출당 토큰
issue/PR 메타데이터의 경우 200–500개 토큰; 큰 파일 가져오기의 경우 5k+로 증가할 수 있음
금액
모든 GitHub 계정에서 무료. GitHub Enterprise는 더 높은 제한.
팁
제한에 도달하면 GitHub App으로 전환 — 여러 PATs를 관리하는 것보다 쉽고 3배의 속도 제공. 반복할 때 list_issues 결과 캐시.

보안

권한, 시크릿, 파급범위

최소 스코프: repo:read issues:read
자격 증명 저장: 환경 변수의 세분화된 PAT (예: GITHUB_PERSONAL_ACCESS_TOKEN). 절대 dotfiles에 커밋하지 않기.
데이터 외부 송신: 모든 API 호출은 api.github.com으로만. 제3자 원격측정 없음.
절대 부여 금지: admin:org delete_repo admin:enterprise

문제 해결

자주 발생하는 오류와 해결

401 Unauthorized

PAT가 만료되었거나 해당 저장소에 대한 접근 권한이 없습니다. github.com/settings/tokens에서 올바른 범위로 다시 생성하세요.

확인: curl -H "Authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN" https://api.github.com/user
403 rate limit exceeded

personal PAT에서 시간당 5000개 요청에 도달했습니다. 재설정 창까지 기다리거나 GitHub App 토큰으로 마이그레이션하세요(15k/h).

확인: curl -H "Authorization: Bearer $TOKEN" https://api.github.com/rate_limit
404 Not Found on a private repo

PAT의 허용 저장소 목록에 해당 저장소가 포함되어 있지 않습니다. 세분화된 PAT를 편집하고 저장소를 추가하세요.

Docker: 'unable to find image'

먼저 이미지 가져오기: docker pull ghcr.io/github/github-mcp-server. 개인 저장소인 경우 ghcr.io에 인증되었는지 확인하세요.

확인: docker images | grep github-mcp-server

대안

GitHub 다른 것과 비교

대안언제 쓰나단점/장점
GitLab MCPGitHub 대신 GitLab.com 또는 자체 호스팅 GitLab을 사용할 때더 작은 기능 표면, 커뮤니티 유지
Gitea MCP자체 호스팅 Gitea 설치공식 GitHub MCP에 비해 제한된 도구
git MCP원격 작업 없이 로컬 git 작업(status, log, diff, blame)만 필요할 때issues, PRs 또는 원격 작업 없음 — 인증 없이 모든 로컬 저장소에서 작동

더 보기

리소스

📖 GitHub에서 공식 README 읽기

🐙 열린 이슈 보기

🔍 400+ MCP 서버 및 Skills 전체 보기