Contributing Guidelines
Relevant source files
The following files were used as context for generating this wiki page:
The GitHub MCP Server project welcomes contributions aimed at supporting high-quality, high-impact capabilities that advance agentic workflows. These guidelines provide a structured framework for developers to propose changes, maintain code quality, and adhere to community standards. The project is maintained by GitHub staff and the community, focusing on delivering clear value to developers through the Model Context Protocol.
Sources: CONTRIBUTING.md:1-15, SUPPORT.md:1-12
Contribution Philosophy
The project prioritizes features that demonstrate practical value through real-world use cases. Before submitting a pull request, contributors are encouraged to create an issue to outline the scenario and potential impact. This allows the maintainers to triage requests promptly and prioritize development effort effectively. Community engagement, such as comments or evidence of real-world use, often influences the revisit and approval of stalled requests.
Sources: CONTRIBUTING.md:17-28
Standards and Conduct
Contributors are expected to adhere to the Contributor Covenant Code of Conduct to ensure a harassment-free experience. This applies to all community spaces and instances where an individual represents the project.
Behavioral Expectations
Positive behaviors include demonstrating empathy, accepting constructive feedback, and focusing on the community's best interests. Unacceptable behaviors include harassment, derogatory comments, or the publication of private information.
Enforcement Process
Community leaders are responsible for enforcing standards and have the right to reject contributions not aligned with the code of conduct. The enforcement hierarchy follows a graduated approach:
| Level | Impact | Consequence |
|---|---|---|
| Correction | Inappropriate language | Private written warning and possible public apology |
| Warning | Single incident/violation | Warning with specified period of restricted interaction |
| Temporary Ban | Sustained inappropriate behavior | Specified period of ban from community interaction |
| Permanent Ban | Pattern of violation/harassment | Permanent ban from all project public interaction |
Sources: CODE_OF_CONDUCT.md:1-110
Pull Request Lifecycle
The pull request (PR) process is designed to ensure that all changes are tested, linted, and documented before being merged into the main branch.
PR Submission Flow
The following diagram illustrates the lifecycle of a contribution from local setup to final submission:
The flow ensures that every PR is self-contained and does not break existing functionality or documentation.
Sources: CONTRIBUTING.md:38-55
Prerequisites for Development
Contributors must install the following tools locally:
- Go: Required for building and running the server.
- golangci-lint v2: The primary linter for maintaining code style.
Sources: CONTRIBUTING.md:30-36
Testing and Documentation Automation
A critical requirement for all contributions is the maintenance of automated documentation and the passing of end-to-end tests.
Automated Documentation Generation
The project uses a custom tool located in cmd/github-mcp-server/generate_docs.go to keep README.md and docs/remote-server.md synchronized with the actual tool implementations.
This tool uses mock clients to introspect the available toolsets and generate Markdown tables and details blocks. Contributors must run script/generate-docs if they modify tool definitions.
Sources: cmd/github-mcp-server/generate_docs.go:23-80, CONTRIBUTING.md:50
Testing Standards
The project utilizes both unit tests and end-to-end (e2e) tests. E2E tests often require a Docker environment and specific environment variables like GITHUB_MCP_SERVER_E2E_TOKEN. Snapshot testing is used for tool definitions; if a tool's parameters change, the developer must run tests with UPDATE_TOOLSNAPS=true.
Sources: CONTRIBUTING.md:49-50, e2e/e2e_test.go:30-60
Security and Support
Reporting Vulnerabilities
Security issues should not be reported via public issues. Instead, contributors should email opensource-security@github.com with a description of the issue, paths to affected source files, and a proof-of-concept.
Sources: SECURITY.md:1-25
Getting Help
For general support, bugs, or questions, contributors should use GitHub Issues. The project follows a "best effort" response policy by both GitHub staff and the community.
Sources: SUPPORT.md:1-12
Summary
Contributing to the GitHub MCP Server requires a focus on practical utility, strict adherence to automated testing/linting, and a commitment to community conduct. By utilizing the provided automation scripts for documentation and testing, contributors help maintain a robust and reliable toolset for agentic workflows.
Sources: CONTRIBUTING.md:17-20, SUPPORT.md:8-10