Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
110 lines (71 loc) · 3.23 KB

CONTRIBUTING.md

File metadata and controls

110 lines (71 loc) · 3.23 KB

Contributing

Thank you for your interest in contributing to the MCP Python SDK! This document provides guidelines and instructions for contributing.

Development Setup

  1. Make sure you have Python 3.10+ installed
  2. Install uv
  3. Fork the repository
  4. Clone your fork: git clone https://github.com/YOUR-USERNAME/python-sdk.git
  5. Install dependencies:
uv sync --frozen --all-extras --dev
  1. Set up pre-commit hooks:
uv tool install pre-commit --with pre-commit-uv --force-reinstall

Development Workflow

  1. Choose the correct branch for your changes:

    • For bug fixes to a released version: use the latest release branch (e.g. v1.1.x for 1.1.3)
    • For new features: use the main branch (which will become the next minor/major version)
    • If unsure, ask in an issue first

  2. Create a new branch from your chosen base branch

  3. Make your changes

  4. Ensure tests pass:

uv run pytest
  1. Run type checking:
uv run pyright
  1. Run linting:
uv run ruff check .
uv run ruff format .
  1. Update README snippets if you modified example code:
uv run scripts/update_readme_snippets.py
  1. (Optional) Run pre-commit hooks on all files:
pre-commit run --all-files
  1. Submit a pull request to the same branch you branched from

Dependency Update Policy

See DEPENDENCY_POLICY.md for the full dependency update policy.

When bumping a dependency version manually, update the constraint in pyproject.toml then run uv lock --resolution lowest-direct (see RELEASE.md).

Security-relevant dependency updates (P0) are applied within 7 days of public disclosure and backported to active release branches.

The SDK currently supports Python 3.10 through 3.13. New CPython releases are supported within one minor SDK release of their stable release date.

Triage Process

New issues are triaged by a maintainer within 2 business days. Triage means adding an appropriate label and determining whether the issue is valid.

Issues are labeled per the SDK Tiering System:

  • Type (pick one): bug, enhancement, question
  • Status (pick one): needs confirmation, needs repro, ready for work, good first issue, help wanted
  • Priority (if actionable): P0, P1, P2, P3

P0 issues are security vulnerabilities (CVSS ≥ 7.0) or core functionality failures that prevent basic MCP operations (connection establishment, message exchange, or use of core primitives). P0 issues must be resolved within 7 days.

Code Style

  • We use ruff for linting and formatting
  • Follow PEP 8 style guidelines
  • Add type hints to all functions
  • Include docstrings for public APIs

Pull Request Process

  1. Update documentation as needed
  2. Add tests for new functionality
  3. Ensure CI passes
  4. Maintainers will review your code
  5. Address review feedback

Code of Conduct

Please note that this project is released with a Code of Conduct. By participating in this project you agree to abide by its terms.

License

By contributing, you agree that your contributions will be licensed under the MIT License.