UniProt MCP Server

# Repository Guidelines ## Project Structure & Module Organization Source lives under `src/uniprot_mcp/` with clear separation of concerns: adapters (`adapters/uniprot_client.py`, `adapters/parsers.py`), domain models (`models/domain.py`), transport surfaces (`server.py` for stdio, `http_app.py` for Streamable HTTP, `__main__.py` for CLI dispatch), and prompts (`prompts.py`). Integration, unit, and fixture data mirror that layout under `tests/`. Keep docs in `docs/` (e.g., `registry.md`) and ensure README/RUNNING stay authoritative when you add modules or rename packages. ## Build, Test, and Development Commands Use uv for every workflow. Sync deps with `uv sync --group dev`. Validate changes before review: `uv tool run ruff check .`, `uv tool run ruff format --check .`, `uv tool run mypy src`, and `uv run pytest --maxfail=1 --cov=uniprot_mcp --cov-report=term-missing`. Launch transports via `uv run uniprot-mcp` (stdio) or `uv run python -m uvicorn uniprot_mcp.http_app:app --reload`. Build artifacts with `uv build`; publish using `uv publish --token $PYPI_TOKEN`. ## Coding Style & Naming Conventions Follow PEP 8 with four-space indentation, snake_case functions, and PascalCase models. All public functions, tools, and adapters must carry type hints and docstrings describing UniProt behaviour or MCP side effects. Keep configuration (ruff, mypy, pytest, coverage) centralized in `pyproject.toml`. Update the README’s command matrix whenever you adjust tooling flags or minimum Python versions. ## Testing Guidelines Unit tests should isolate adapters and parsers, exercising retry logic, GO parsing, and accession validation. Integration tests belong in `tests/integration/` and should rely on recorded VCR fixtures stored in `tests/fixtures/`. Maintain coverage ≥85 %; if you skip a scenario because UniProt is flaky, mark it with `pytest.mark.xfail` and explain the upstream issue in a comment. Run `act -W .github/workflows/ci.yml` after editing workflows to ensure local parity with GitHub-hosted runners. ## Commit & Pull Request Guidelines Use Conventional Commits (`feat:`, `fix:`, `chore:`, `docs:`) and keep scopes short. Every PR needs a summary, links to issues or milestones, validation output (copy the uv/pytest commands above), README/RUNNING updates when behaviour changes, and confirmation that `server.json` and packaging metadata remain accurate. Rebase on `main` before review; avoid force pushes after approvals unless you coordinate on the thread. ## Release & Registry Publishing For releases, bump the version (`uv version --bump <level>`), regenerate artifacts (`uv build`), run the full validation stack, and tag (`git tag vX.Y.Z`). Validate `server.json` per `docs/registry.md`, then call `mcp-publisher publish` so MCP clients and the Registry can discover the new package or remote endpoint.