fix: version drift, bypassed output validation, and tests shipped in the wheel

[PietjePuh]

Three independent fixes, one commit each. Full CI gate passes locally (ruff check, ruff format --check, mypy, pytest), plus uvx twine check on the rebuilt artifacts and a read-only smoke test against the live Jules API.

---

1. The server advertises the wrong version

jules_mcp/jules_mcp.py hardcoded version: Final[str] = "0.1.3" while pyproject.toml declares 0.1.6. FastMCP("Jules MCP Server", version=version) passes that straight to clients, so every MCP client has been told the wrong version.

Now read from installed distribution metadata via importlib.metadata, with a fallback constant for source-checkout runs (fastmcp run jules_mcp/jules_mcp.py, used by the Dockerfile and MCP.json).

2. Output-schema validation was disabled for three tools

tests/test_jules_mcp/conftest.py monkeypatched FastMCP internals at module-load time:

if fn.__name__ in ("create_session", "get_session", "wait_for_session_completion"):
    if "return" in fn.__annotations__:
        fn.__annotations__["return"] = dict

Rewriting the return annotation to dict replaces the generated Session output schema with a permissive one, so a quarter of the tool surface ran with no meaningful output validation.

It was compensating for a malformed fixture, not a library bug. mock_session_dict had a top-level "source" key — not a field on models.Session — and "source_context": {"source_name": ...} where models.SourceContext requires source. The old fixture fails with Output validation error: 'source' is a required property once the patch is removed.

Fixture corrected, patch deleted. Verified all 12 tools still expose a non-null outputSchema without it.

3. The published wheel ships a top-level tests package

pyproject.toml had no [build-system] table, and [tool.setuptools.packages.find] had no include filter. Building 0.1.6 as-is produces:

top_level.txt -> "jules_mcp\ntests"

jules_mcp/__init__.py
jules_mcp/__main__.py
jules_mcp/jules_mcp.py
jules_mcp/py.typed
tests/test_jules_mcp/__init__.py      <-- shipped to PyPI
tests/test_jules_mcp/conftest.py      <-- shipped to PyPI
tests/test_jules_mcp/test_mcp_server.py

So pip install jules-mcp installs a top-level tests package into the user's site-packages, where it can shadow or collide with anything else of that name. This affects the released artifact, not just the repo.

The missing [build-system] had a second effect: uv classified the project as virtual (source = { virtual = "." } in uv.lock) and never installed it, so importlib.metadata could not resolve the distribution and the fix in (1) always took its fallback path.

Declaring the setuptools backend and constraining discovery to jules_mcp* fixes both. After the change:

top_level.txt -> "jules_mcp"
wheel contains only jules_mcp/
uv.lock: source = { virtual = "." }  ->  source = { editable = "." }

uv.lock is regenerated in the same commit because CI runs uv sync --locked, which would otherwise fail against the changed project source type. The lock diff is a single line.

---

Regression guards

Added TestVersion and TestPackaging. Both were confirmed to fail when the original defects are reintroduced, rather than passing vacuously:

• restoring 0.1.3 → both version assertions fail
• removing the include filter → test_tests_package_is_not_shipped fails

Verification

ruff check .            All checks passed!
ruff format --check .   6 files already formatted
mypy .                  Success: no issues found in 3 source files
pytest                  16 passed   (was 12)
uvx twine check dist/*  PASSED (wheel + sdist)

Also exercised read-only against a live Jules API account — list_sources, get_all_sources, list_sessions, get_session, list_activities all pass, confirming real Session payloads validate against the schema this PR re-enables. Details in the comment below.

Not included

The Dockerfile looks like it has a separate issue: RUN uv sync --no-dev builds /app/.venv, but the ENTRYPOINT is uv run --with fastmcp --with jules-agent-sdk --with requests fastmcp run .... Those unpinned --with flags re-resolve dependencies at container start, bypassing uv.lock and requiring network at runtime. I had no Docker daemon available to build-test a change, so I left it out rather than ship something unverified. Happy to open a separate PR.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[PietjePuh]

Follow-up: I've now validated this against a live Jules API account, not just mocks. That was the one real risk in this PR — the existing fixtures return plain dicts, while the SDK returns dataclasses, so removing the output-schema bypass needed proof that genuine API payloads validate.

Read-only calls only (list_sources, get_all_sources, list_sessions, get_session, list_activities). No session was created, approved, or messaged.

server version advertised: 0.1.6
tools registered: 12
[PASS] list_sources        -> 5 source(s), nextPageToken=yes
[PASS] get_all_sources     -> 32 source(s)
[PASS] list_sessions       -> 5 session(s)   <-- real Session payloads
[PASS] get_session         -> state=AWAITING_USER_FEEDBACK
[PASS] list_activities     -> 1 activity(ies)

RESULT: ALL READ-ONLY CALLS PASSED

Two things this confirms:

1. get_session and list_sessions validate against the real Session output schema. These are two of the three tools whose validation the conftest.py patch was suppressing. Live responses pass the schema unmodified, so the patch was never protecting against a genuine incompatibility — only against the malformed fixture.
2. The version fix works end-to-end. The server reports 0.1.6 from installed distribution metadata, matching pyproject.toml, where it previously reported 0.1.3.

Account-identifying details (source names, session titles) omitted deliberately.