Thanks for your interest in contributing to mcpx! Here's how to get started.
# Clone
git clone https://github.com/codestz/mcpx.git
cd mcpx
# Build
make build
# Run tests
make test
# Lint
make lintRequirements: Go 1.24+
- Fork the repository
- Create a branch from
main:git checkout -b my-feature - Make your changes — keep them focused and minimal
- Add tests for new functionality
- Run the checks:
go build ./cmd/mcpx go vet ./... go test -race ./... - Commit with a clear message describing the why
- Open a pull request against
main
- Follow standard Go conventions (
gofmt,go vet) - Keep functions short and focused
- Error messages include context:
fmt.Errorf("config: load %s: %w", path, err) - No global state — packages receive dependencies explicitly
- Table-driven tests with subtests
cmd/mcpx/ entrypoint (thin — calls cli.Execute())
internal/
config/ leaf package, zero internal deps
secret/ leaf package, zero internal deps
resolver/ depends on secret
mcp/ zero internal deps (receives resolved strings)
daemon/ depends on mcp, config
cli/ orchestrator — wires everything together
Rule: config and secret are leaf packages. cli is the only place that imports multiple internal packages.
- One concern per PR — a bug fix, a feature, or a refactor. Not all three.
- Tests included — if you add behavior, add a test. If you fix a bug, add a test that would have caught it.
- No unrelated changes — don't reformat files you didn't modify, don't add comments to code you didn't change.
- Clear description — explain what and why, not how (the code shows how).
Open an issue with:
- What you expected to happen
- What actually happened
- Steps to reproduce
mcpx versionoutput- OS and Go version
Open an issue describing the use case. Focus on the problem you're solving, not the specific solution. We'll discuss the approach together.
If you find a security vulnerability, please report it privately. See SECURITY.md for details.
By contributing, you agree that your contributions will be licensed under the MIT License.