Skip to content
FastMCP Feedback

Contributing

The package is developed in the open at git.supported.systems/fastmcp-feedback/fastmcp-feedback. Bug reports and feature requests go to its issue tracker. A good report names the package and FastMCP versions and includes a few lines of code that show the problem.

Set up a checkout

Section titled “Set up a checkout”
Terminal window
git clone https://git.supported.systems/fastmcp-feedback/fastmcp-feedback.git
cd fastmcp-feedback
uv venv
uv pip install -e ".[dev]"
uv run pytest -q --no-cov

Without a database server, the PostgreSQL variants of the database tests skip and everything else runs on SQLite.

Run the tests against PostgreSQL

Section titled “Run the tests against PostgreSQL”

The repository has a compose stack with PostgreSQL 16 and pgvector, published on 127.0.0.1 only. Docker is required.

Terminal window
make pg-up      # start it and wait until healthy (writes .env on first run)
make test-pg    # whole suite, PostgreSQL cases enabled
make test       # whole suite, SQLite only
make pg-down    # stop it; the data volume is kept (pg-reset deletes it)

Each PostgreSQL test gets a freshly created database with the vector extension, dropped afterwards. To use another server, set FFB_TEST_DATABASE_URL to an async URL for a user that may create databases.

Before you send a change

Section titled “Before you send a change”
  • uv run ruff check src/ passes.
  • New behavior has tests; database behavior has them on both backends (the db_url fixture in tests/conftest.py gives each test an empty database).
  • The README and CHANGELOG.md describe the change, and every Python example in the README still runs.

Versioning

Section titled “Versioning”

Releases use calendar versioning: YYYY.MM.DD, with .1, .2 for further releases on the same day. A release that changes behavior says so in the changelog under “Changed”, with what to do about it.