Github Issues

GitHub issues

Create, update, query, and organize GitHub issues with MCP read tools and gh api write operations, including issue types, labels, milestones, sub-issues, dependencies, project fields, and image embeds.

When to invoke

• "Create an issue for this bug."
• "File a feature request in GitHub."
• "Update issue 123 and set the priority."
• "Add a blocked-by relationship between these issues."
• "Link this task to a milestone and project field."

Manage GitHub issues using the @modelcontextprotocol/server-github MCP server.

Available Tools

MCP Tools (read operations)

CLI / REST API (write operations)

The MCP server does not currently support creating, updating, or commenting on issues. Use gh api for these operations.

Note: gh issue create works for basic issue creation but does not support the --type flag. Use gh api when you need to set issue types.

Workflow

1. Determine action: Create, update, or query?
2. Gather context: Get repo info, existing labels, milestones if needed
3. Structure content: Use appropriate template from references/templates.md
4. Execute: Use MCP tools for reads, gh api for writes
5. Confirm: Report the issue URL to user

Creating Issues

Use gh api to create issues. This supports all parameters including issue types.

gh api repos/{owner}/{repo}/issues \
  -X POST \
  -f title="Issue title" \
  -f body="Issue body in markdown" \
  -f type="Bug" \
  --jq '{number, html_url}'

Optional Parameters

Add any of these flags to the gh api call:

-f type="Bug"                    # Issue type (Bug, Feature, Task, Epic, etc.)
-f labels[]="bug"                # Labels (repeat for multiple)
-f assignees[]="username"        # Assignees (repeat for multiple)
-f milestone=1                   # Milestone number

Issue types are organization-level metadata. To discover available types, use:

gh api graphql -f query='{ organization(login: "ORG") { issueTypes(first: 10) { nodes { name } } } }' --jq '.data.organization.issueTypes.nodes[].name'

Prefer issue types over labels for categorization. When issue types are available (e.g., Bug, Feature, Task), use the type parameter instead of applying equivalent labels like bug or enhancement. Issue types are the canonical way to categorize issues on GitHub. Only fall back to labels when the org has no issue types configured.

Title Guidelines

• Be specific and actionable
• Keep under 72 characters
• When issue types are set, don't add redundant prefixes like [Bug]
• Examples:
  • Login fails with SSO enabled (with type=Bug)
  • Add dark mode support (with type=Feature)
  • Add unit tests for auth module (with type=Task)

Body Structure

Always use the templates in references/templates.md. Choose based on issue type:

Updating Issues

Use gh api with PATCH:

gh api repos/{owner}/{repo}/issues/{number} \
  -X PATCH \
  -f state=closed \
  -f title="Updated title" \
  --jq '{number, html_url}'

Only include fields you want to change. Available fields: title, body, state (open/closed), labels, assignees, milestone.

Examples

Example 1: Bug Report

User: "Create a bug issue - the login page crashes when using SSO"

Action:

gh api repos/github/awesome-copilot/issues \
  -X POST \
  -f title="Login page crashes when using SSO" \
  -f type="Bug" \
  -f body="## Description
The login page crashes when users attempt to authenticate using SSO.

## Steps to Reproduce
1. Navigate to login page
2. Click 'Sign in with SSO'
3. Page crashes

## Expected Behavior
SSO authentication should complete and redirect to dashboard.

## Actual Behavior
Page becomes unresponsive and displays error." \
  --jq '{number, html_url}'

Example 2: Feature Request

User: "Create a feature request for dark mode with high priority"

Action:

gh api repos/github/awesome-copilot/issues \
  -X POST \
  -f title="Add dark mode support" \
  -f type="Feature" \
  -f labels[]="high-priority" \
  -f body="## Summary
Add dark mode theme option for improved user experience and accessibility.

## Motivation
- Reduces eye strain in low-light environments
- Increasingly expected by users

## Proposed Solution
Implement theme toggle with system preference detection.

## Acceptance Criteria
- [ ] Toggle switch in settings
- [ ] Persists user preference
- [ ] Respects system preference by default" \
  --jq '{number, html_url}'

Common Labels

Use these standard labels when applicable:

Tips

• Always confirm the repository context before creating issues
• Ask for missing critical information rather than guessing
• Link related issues when known: Related to #123
• For updates, fetch current issue first to preserve unchanged fields

Extended Capabilities

The following features require REST or GraphQL APIs beyond the basic MCP tools. Each is documented in its own reference file so the agent only loads the knowledge it needs.

Progressive disclosure and bundled resources

• references/templates.md: issue body templates for Bug Report, Feature Request, and Task.
• references/search.md: advanced search syntax and issue field filters.
• references/sub-issues.md: parent and sub-issue workflows.
• references/milestones.md: milestone CRUD and issue assignment.
• references/dependencies.md: blocked-by and blocking relationships.
• references/issue-types.md: advanced issue type operations.
• references/projects.md: Projects V2 field and board workflows.
• references/issue-fields.md: custom metadata fields.
• references/images.md: embedding images in issue bodies and comments.

Output template

## GitHub issue result

**Status:** created | updated | queried | blocked
**Repository:** `{{owner}}/{{repo}}`
**Issue:** `#{{number}}` {{html_url}}

### Changes
| Field | Value |
| --- | --- |
| Title | {{title}} |
| Type | {{type_or_none}} |
| Labels | {{labels_or_none}} |
| Assignees | {{assignees_or_none}} |
| Milestone | {{milestone_or_none}} |

### Commands or tools
- `{{mcp_read_tool_or_gh_api_command}}`

Quality gate

• Repository context is confirmed before creating or updating an issue.
• Issue content uses the matching template from references/templates.md.
• Issue types are preferred over redundant categorization labels when available.
• gh api is used for writes that require unsupported gh issue create fields such as type.
• The final response includes the issue number and URL or a clear blocker.