Automates GitHub operations including branch creation, running tests, committing/pushing changes, and creating pull requests.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@github-workflow-mcp Create branch 'add-login', add login button, run tests, commit, and open PR."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Claude Code에 자연어 지시 한 번으로 GitHub 워크플로우를 자동화하는 MCP 서버.
브랜치 생성 → 코드 작성 → 테스트 → 커밋/Push → PR 오픈까지 한 번에 처리합니다.
Related MCP server: GitHub MCP Server
분류 | 기술 | 버전 | 역할 |
런타임 | Node.js | ≥ 18 | ESM 모듈 시스템, native |
MCP |
| ^1.17.5 | stdio 기반 MCP 서버 ( |
스키마 검증 |
| ^3.25.76 | 도구 입력 파라미터 런타임 타입 검증 |
AI 코드 생성 |
| ^0.104.1 | Claude Sonnet 4.6 호출 ( |
GitHub API | REST API v3 | — | native |
Git 조작 |
| — |
|
테스트 |
| built-in | 외부 프레임워크 없이 26개 단위 테스트 |
Claude Code (사용자)
│ 자연어 지시
▼
┌─────────────────────────────┐
│ server.js │ ← MCP 서버 진입점
│ createServer(env) │ 도구 등록 + 의존성 주입
│ 8개 Tools / 2개 Resources │
│ 1개 Prompt │
└──────┬──────────────────────┘
│
┌────┴────────────────────┐
│ │
▼ ▼
githubClient.js aiClient.js
GitHub REST API v3 호출 Claude API 호출
브랜치/PR/이슈/라벨 관리 코드 생성 + 파일 쓰기
git CLI 실행 레포 컨텍스트 수집의존성 주입 패턴: 모든 tool handler는 두 번째 인자 { _functionName } 형태로 실제 함수를 주입받습니다. 테스트 시 mock 함수를 주입해 GitHub API / Anthropic API 없이 완전한 단위 테스트가 가능합니다.
// 실제 실행
runCreateBranchTool(args, { token, owner, repo, defaultBase })
// 테스트에서 mock 주입
runCreateBranchTool(args, {
_getBranchSha: async () => 'sha-abc',
_createBranch: async () => {},
})도구 | 파라미터 | 설명 |
| — | 레포에 존재하는 라벨 목록 조회. |
|
| 이슈 생성. 없는 라벨은 거부하고 사용 가능한 목록 반환 |
도구 | 파라미터 | 설명 |
|
| GitHub 브랜치 생성 (REST API로 원격 브랜치 직접 생성) |
|
| 테스트 실행 후 pass/fail + 전체 출력 반환. 허용 명령어만 실행 |
|
| 변경사항 스테이징 → 커밋 → push |
|
| Pull Request 생성 후 URL 반환 |
|
| PR 리뷰 승인/변경 요청 수 및 인라인 코멘트 요약 |
ANTHROPIC_API_KEY환경 변수가 없으면isError: true를 반환하며 비활성 상태가 됩니다.
도구 | 파라미터 | 설명 |
|
| 원클릭 자동화 — 브랜치 생성 → AI 코드 작성 → 테스트 (실패 시 최대 3회 자동 수정) → 커밋/push → PR |
Tools가 Claude가 실행하는 함수라면, Resources는 Claude가 읽어오는 데이터 소스입니다. 대화 시작 전에 첨부하면 Claude가 레포 컨텍스트를 가진 상태로 응답합니다.
URI | 설명 |
| 레포 파일 트리 + 주요 파일 내용. 코드 작성 전 레포 구조 파악에 사용 |
| 최근 PR 10개 목록 (제목, URL, 브랜치, 상태). 진행 중인 작업 파악에 사용 |
Claude Code에서 첨부하는 법: 대화창에서 @ 입력 후 URI를 선택합니다.
@ repo://context
@ repo://recent-prsPrompts는 자주 쓰는 지시 패턴을 템플릿으로 등록한 것입니다. Claude Desktop 등에서 / 커맨드로 불러올 수 있습니다.
이름 | 파라미터 | 설명 |
|
| 브랜치 생성 → 코드 작성 → 테스트 → 커밋 → PR 순서를 안내하는 표준 워크플로우 프롬프트 |
Claude Code에서 사용하는 법:
/workflow task="로그인 버튼 컴포넌트 추가"내부적으로 아래 내용을 Claude에게 전달합니다:
Please implement the following task using the github-workflow MCP tools:
**Task:** 로그인 버튼 컴포넌트 추가
Follow these steps in order:
1. Attach the `repo://context` resource to understand the codebase
2. Call `create_branch` with a descriptive branch name
3. Write or modify the necessary files
4. Call `run_tests` to verify correctness
5. Call `commit_and_push` with a clear commit message
6. Call `create_pr` to open a Pull RequestClaude Code가 각 MCP 도구를 순서대로 호출합니다. AI 코딩 없이 사람이 작성한 코드를 Git 워크플로우에 연결할 때 사용합니다.
사용자: "feature/login-button 브랜치 만들고 테스트 통과하면 PR 열어줘"
Claude Code
1. create_branch("feature/login-button") → GitHub API: refs 생성
2. (코드 작성은 Claude Code 자체가 수행)
3. run_tests("npm test") → spawn("npm", ["test"], cwd)
└ 실패 시 Claude Code가 직접 코드 수정 후 재시도
4. commit_and_push("feat: add login button") → git add . && git commit && git push -u origin HEAD
5. create_pr("Add login button", ...) → GitHub API: pulls 생성run_workflow 원클릭 자동화 (Claude API 내장)run_workflow 도구 하나만 호출하면 모든 단계를 내부에서 처리합니다. AI가 코드까지 작성합니다.
사용자: "아바타 업로드 기능 추가해줘"
run_workflow("아바타 업로드 기능 추가")
│
├─ 1. 브랜치 생성
│ generateBranchName(task) → "feature/아바타-업로드-기능-추가"
│ getBranchSha(master) → createBranch(feature/...)
│
├─ 2. 코드 생성 루프 (최대 3회 시도)
│ │
│ ├─ buildRepoContext(repoPath)
│ │ └ 파일 트리 수집 (node_modules, .git 제외)
│ │ 우선순위: package.json → *.json/*.md → src/* → 나머지
│ │ 최대 20개 파일, 파일당 32,000자 제한
│ │
│ ├─ generateCodeChanges(client, task, context, previousError)
│ │ └ Claude Sonnet 4.6 호출 (max_tokens: 8192)
│ │ 응답 형식: { explanation, files: [{path, content}] }
│ │ 재시도 시 이전 테스트 실패 출력을 함께 전달
│ │
│ ├─ applyFileChanges(repoPath, files)
│ │ └ 생성된 파일을 디스크에 저장
│ │
│ └─ run_tests("npm test", repoPath)
│ ├ PASS → 루프 종료
│ └ FAIL → previousTestOutput 저장 후 다음 시도
│
├─ 3. commitAndPush(repoPath, "feat: {task}", ["."])
│ git add . → git commit -m ... → git push -u origin HEAD
│
└─ 4. createPR(task, body, branchName, master)
→ PR URL + number 반환create_issue)GitHub는 존재하지 않는 라벨을 이슈 생성 시 자동으로 만들어버립니다 (레포 라벨 오염). 이를 방지하기 위해 사전 검증합니다.
create_issue(title, labels=["bug", "없는라벨"])
│
├─ labels가 비어있으면 → 검증 스킵, 바로 생성
│
├─ listLabels(owner, repo) → 레포 라벨 전체 조회
│
├─ 요청 라벨 ∩ 존재 라벨 비교
│ ├─ 모두 존재 → createIssue() 호출
│ └─ 없는 라벨 발견 → isError: true 반환
│ "Label(s) not found: "없는라벨""
│ "Available labels: bug, enhancement, ..."
│
└─ AI가 list_labels 재호출 후 올바른 라벨로 재시도git clone https://github.com/GHeeJeon/github-workflow-mcp
cd github-workflow-mcp
npm install
npm link # 전역 바이너리 등록 (github-workflow-mcp 커맨드 사용 가능)팀 공유 시 npm 패키지로 직접 설치:
npm install /path/to/github-workflow-mcpclaude mcp add 명령어로 등록합니다. 프로젝트 디렉토리에서 실행하세요.
claude mcp add github-workflow \
-e GITHUB_TOKEN=ghp_your_token_here \
-e REPO_OWNER=yourorg \
-e REPO_NAME=your-project \
-e REPO_PATH=/Users/you/projects/your-project \
-e DEFAULT_BASE_BRANCH=main \
-- github-workflow-mcprun_workflow (AI 자동화)까지 사용하려면 ANTHROPIC_API_KEY를 추가합니다:
claude mcp add github-workflow \
-e GITHUB_TOKEN=ghp_your_token_here \
-e REPO_OWNER=yourorg \
-e REPO_NAME=your-project \
-e REPO_PATH=/Users/you/projects/your-project \
-e ANTHROPIC_API_KEY=sk-ant-your_key_here \
-- github-workflow-mcp연결 확인:
claude mcp list
# github-workflow: github-workflow-mcp - ✔ Connected변수 | 필수 | 설명 |
| ✓ | GitHub Personal Access Token ( |
| ✓ | 대상 레포 owner (예: |
| ✓ | 대상 레포 이름 (예: |
| ✓ | 로컬 레포 절대 경로 (예: |
| — | 기본 베이스 브랜치 (기본값: |
| — | Claude API 키 ( |
GitHub Token 발급: Settings → Developer settings → Personal access tokens → repo 스코프 체크
Claude Code에서 자연어로 지시하면 MCP 도구를 순서대로 호출합니다.
"feature/login-button 브랜치를 만들고, 로그인 버튼 컴포넌트를 작성한 뒤
테스트 통과하면 PR까지 열어줘."Claude Code가 자동으로 호출하는 순서:
create_branch("feature/login-button")
(Claude Code 자체가 코드 작성)
run_tests("npm test") — 실패 시 코드 수정 후 재시도
commit_and_push("feat: add login button")
create_pr("Add login button", "...", "feature/login-button")
run_workflow)"run_workflow로 '사용자 프로필 페이지에 아바타 업로드 기능 추가' 해줘"내부에서 Claude API가 코드를 작성하고 테스트까지 통과시킵니다.
"bug 라벨로 '로그인 버튼이 클릭되지 않음' 이슈 만들어줘"Claude Code가 자동으로 호출하는 순서:
list_labels() — 사용 가능한 라벨 확인
create_issue("로그인 버튼이 클릭되지 않음", labels=["bug"])
"https://github.com/myorg/repo/pull/42 리뷰 상태 알려줘"get_pr_review_summary 가 승인 수 / 변경 요청 수 / 인라인 코멘트를 요약해 반환합니다.
Tools를 호출하기 전에 Resource를 첨부하면 Claude가 레포 구조를 파악한 상태로 작업을 시작합니다.
@ repo://context 첨부 후:
"위 구조를 보고 인증 모듈에 refresh token 기능을 추가해줘"@ repo://recent-prs 첨부 후:
"현재 진행 중인 PR 중 리뷰어가 없는 것 있어?"두 Resource를 함께 첨부하면 Claude가 레포 구조와 진행 중인 PR을 동시에 파악합니다:
@ repo://context @ repo://recent-prs
"현재 작업 중인 PR과 겹치지 않도록 새 브랜치 만들어서 다크모드 지원 추가해줘"workflow 프롬프트는 전체 단계 안내를 자동으로 포함합니다:
/workflow task="사용자 프로필 이미지 업로드 기능 추가"run_workflow 와의 차이: workflow 프롬프트는 Claude Code 자체가 코드를 작성하는 Part B 방식이고, run_workflow 는 내장 Claude API가 코드까지 생성하는 Part A 방식입니다.
npm test26개 단위 테스트가 포함되어 있습니다. 모든 테스트는 GitHub API / Anthropic API를 호출하지 않으며 의존성 주입으로 완전히 mock 처리됩니다.
커버리지 영역 | 테스트 수 |
| 2 |
| 2 |
| 4 |
| 2 |
| 4 |
| 2 |
| 2 |
| 2 |
| 5 |
합계 | 26 |
명령어 허용 목록: run_tests의 command 파라미터는 npm test, yarn test, pnpm test, python -m pytest만 허용합니다. 임의 셸 명령어 실행을 차단합니다.
라벨 사전 검증: create_issue는 존재하지 않는 라벨 요청을 API 호출 전에 거부합니다. GitHub의 자동 라벨 생성(레포 오염)을 방지합니다.
경로 고정: REPO_PATH는 MCP 설정에서 명시적으로 지정합니다. 런타임에 임의 경로를 전달할 수 없습니다.
토큰 범위 최소화: GITHUB_TOKEN은 repo 스코프만 필요합니다. 각자 개인 PAT를 사용하면 커밋이 본인 이름으로 기록됩니다.
Stage files, create a commit, and push to the current branch.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Files to stage (default: ["."] — all changes) | |
| message | Yes | Commit message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It outlines the three steps (stage, commit, push) but omits important behavioral details: what happens if there are no changes to commit, whether it pushes to a specific remote, error handling (e.g., merge conflicts), or side effects like overriding local commits. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core functionality without any unnecessary words. It is front-loaded and each word contributes meaning. Ideal conciseness for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the straightforward nature of the tool and the complete parameter schema, the description provides the basic context. However, it lacks detail on return values (no output schema) and does not address edge cases or typical usage scenarios. It is minimally sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('files' and 'message') already well-described in the input schema. The tool description adds no additional semantic detail beyond paraphrasing the schema. Baseline is 3 due to high coverage, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stages files, creates a commit, and pushes to the current branch. It uses specific verbs (Stage, create, push) and identifies the resource (git operations). It is easily distinguishable from sibling tools like create_branch or create_issue, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., being in a git repository, having an upstream configured) or when not to use it (e.g., when needing to force push or handle conflicts). Sibling tools are listed but no comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GitHub branch from a base branch.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base branch to branch from (default: main) | |
| name | Yes | New branch name (e.g. "feature/login-button") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions creating a branch but does not disclose side effects (e.g., failure if branch exists), permissions required, or idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is minimally complete. However, it lacks guidance on error conditions or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'base' and 'name'. The description does not add extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new GitHub branch from a base branch'. It is distinct from sibling tools like commit_and_push or create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (creating a branch from a base), but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GitHub issue. Use list_labels first to pick valid label names — non-existent labels are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Issue body (markdown supported) | |
| title | Yes | Issue title | |
| labels | No | Label names from list_labels (e.g. ["bug", "enhancement"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions rejection of non-existent labels but does not disclose other behavioral traits such as authentication requirements, creation scope (e.g., which repository), idempotency, or side effects. A mutation tool needs more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. The key information is front-loaded: the purpose and a critical usage guideline. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers creation and label validation but omits the return value (e.g., issue number or URL) and potential side effects. For a tool with no output schema, describing the return value would improve completeness. It is minimally adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all three parameters described. The description adds value beyond the schema by specifying that label names must come from list_labels, which clarifies validity constraints. However, it does not add significant meaning for title or body beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a GitHub issue,' specifying the verb and resource. It explicitly mentions using list_labels for label validation and distinguishes from siblings (e.g., create_pr, list_labels) by focusing on issue creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use list_labels first to pick valid label names — non-existent labels are rejected.' This tells the agent when to use a sibling tool as a prerequisite and clarifies that invalid labels cause rejection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a GitHub Pull Request for the given branch.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base branch to merge into (default: main) | |
| body | Yes | PR body (markdown supported) | |
| title | Yes | PR title | |
| branch | Yes | Head branch to merge from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as authentication requirements, idempotency, side effects, or error cases, which is critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action. Efficient but could include more context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and minimal description for a tool with 4 parameters. Missing return value, error handling, and integration cues, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional semantic value beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Open' and resource 'GitHub Pull Request', clearly stating it operates on a branch. It differentiates from sibling tools like create_branch or create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when to avoid it. No mention of prerequisites or alternative tools among siblings, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and summarise all review comments for a Pull Request.
| Name | Required | Description | Default |
|---|---|---|---|
| pr_url | Yes | Full GitHub PR URL (e.g. https://github.com/owner/repo/pull/42) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not specify behavior details such as the format of the summary, authentication requirements, rate limits, or handling of empty review comments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema. The description gives a basic overview but lacks details on return format, error handling, or pagination, which would be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description repeats the schema's description. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch and summarise') and the resource ('all review comments for a Pull Request'). It is specific and distinct from sibling tools like create_pr or list_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's purpose but does not explicitly state when to use it or when to avoid it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available labels in the repository. Call this before create_issue to see which label names are valid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries transparency burden. It clearly states it's a read-only listing operation, but could mention potential limitations like pagination or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded purpose and usage instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-param tool without output schema, the description fully covers what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% with 0 properties. Baseline 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'list', resource 'available labels', and scope 'in the repository'. It also distinguishes the tool from siblings like create_issue by providing a clear usage hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this tool before create_issue to see valid label names, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the test suite and return pass/fail status with full output.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory (default: REPO_PATH env) | |
| command | No | Test command (default: "npm test") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns pass/fail status and full output, but does not mention side effects, error behavior, or permissions. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description adequately explains the tool's action and return value. It is complete enough for typical use, though it could mention that the command parameter has specific enum values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning or context for the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'run' and resource 'test suite', and clearly states it returns pass/fail status with full output. It distinguishes well from sibling tools which are about git operations and workflow running.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like run_workflow. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fully automated workflow: AI generates code, runs tests (retrying up to 3 times on failure), commits, pushes, and opens a PR. Requires ANTHROPIC_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural language description of the feature or fix to implement | |
| branch_name | No | Branch name (default: auto-generated from task) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good transparency: it describes the workflow steps, retry behavior (up to 3 times), and the need for ANTHROPIC_API_KEY. It does not detail failure modes beyond retries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence that packs all essential information without redundancy. It is front-loaded with 'Fully automated workflow' and efficiently lists steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, no output schema, and no nested objects, the description covers the workflow and requirements adequately. It could mention return value or side effects but is still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in the schema. The description does not add additional parameter details, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs a fully automated workflow including code generation, testing, committing, pushing, and PR creation. It distinguishes from sibling tools which are individual steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for automation but does not explicitly state when to use this tool versus individual sibling tools like commit_and_push or run_tests. It mentions the required API key as a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0commit_and_pushcreate_branchcreate_issuecreate_prget_pr_review_summarylist_labelsrun_testsrun_workflowMost tools are clearly distinct (create_branch, create_issue, create_pr, list_labels, get_pr_review_summary). However, run_workflow subsumes commit_and_push and run_tests, potentially causing selection ambiguity. Descriptions mitigate this by specifying that run_workflow is a high-level automated workflow.
All tool names follow a consistent snake_case verb_noun pattern (e.g., create_branch, list_labels, run_tests, get_pr_review_summary). Even compound verbs like commit_and_push adhere to the pattern without mixing styles.
8 tools is well within the typical 3-15 range for a focused MCP server. Each tool serves a distinct purpose in the development workflow, from branching and committing to testing and PR creation, without unnecessary bloat.
The tool set covers the core workflow (branching, committing, testing, PR creation, issue creation) and includes supporting tools (list_labels, get_pr_review_summary). Minor gaps exist: no direct file manipulation, no delete branch, and no tools for managing PRs after creation (e.g., merge). However, the stated purpose is workflow automation, and the set is largely complete for that.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
Autonomous dev team steered from chat: plain-English requests in, tested merged PRs out.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GHeeJeon/github-workflow-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
