v0.3.2

[0.3.2] - 2026-08-02

Fixed

• The User-Agent named no version. Outbound requests carried

  i14y-mcp (+https://github.com/malkreide/i14y-mcp)
  

  Nothing about it was wrong — it claimed no false number — but the operator of
  the data source could not tell which release was calling, which is half the
  reason to send a custom User-Agent at all. It now reads
  i14y-mcp/<version> (+…), interpolated from the package metadata.

  This was the last such case in the portfolio. A fleet-wide probe reported it
  as unverified: a User-Agent was present but no value could be compared
  against the installed version. That is explicitly not a pass — "I could not
  resolve it" and "there is nothing wrong" are different claims.

• __version__ was a literal beside the one in pyproject.toml. Two copies
  of a number the build decides. The same arrangement in hn-tech-signal-mcp
  led to __version__ reporting 0.2.1 while the package shipped as 0.2.4,
  and in swiss-procurement-mcp to a User-Agent announcing 0.4.0 from a
  package that was 0.18.3.

  The version now comes from importlib.metadata in a module of its own,
  _version.py. A separate module rather than __init__, so that client can
  read the version without importing the package root: the root imports
  server, which imports client, and taking the version from a
  partially-initialised root would hold only until somebody reorders two lines.
  bag-health-mcp carries a latent circular import from exactly that shape.

  The fallback for an uninstalled source tree is 0.0.0+source — a PEP 440
  local segment that cannot be read as a release.

• Nothing asserted anything about the User-Agent before. tests/test_user_agent.py
  now checks that it carries the installed version, that __version__ equals it,
  that a version is named at all, and that no version literal returns under
  src/. Verified in the other direction too: with the bare token restored, two
  of the five tests fail.

v0.3.1

[0.3.1] - 2026-08-02

Fixed

• structlog carried no upper bound, and the index already serves a major past
  the floor. The declared range was structlog>=24.1; PyPI has been serving
  26.1.0. The artefact does not change — the resolver's answer to the next
  fresh install does, and that is exactly how swiss-energy-mcp 0.3.3 became
  uninstallable when mcp 2.0.0 removed the module it imported.

  Now structlog>=24.1,<27. The bound is measured rather than guessed: this package
  installs and imports against structlog 26.1.0 today, so the cap admits what
  demonstrably works and stops only the next, unknown major.

A dependency range only reaches users through a new release, hence the
version bump. No code changed.

v0.3.0

[0.3.0] — 2026-08-02

This release exists so that a repair reaches the people running the server:
the published 0.2.1 cannot be installed any more. It declares mcp with
no upper bound, and mcp 2.0.0 removed mcp.server.fastmcp — so a fresh
pip install i14y-mcp resolves to 2.0.0 and the console script dies on
startup with ModuleNotFoundError. Measured against the real artefact in an
empty venv, cold and warm interpreter alike.

The repository has carried the fix since the 2.x migration was merged; it was
simply never released, and main kept the same version number as the broken
artefact — so nothing contradicted it.

Changed (breaking)

• Migrated to the mcp Python SDK 2.x. The server API moved from
  mcp.server.fastmcp to mcp.server.mcpserver with no compatibility shim,
  and the dependency is now mcp>=2.0.0,<3. The tool surface is unchanged —
  what breaks is embedding this server's Python API and the dependency floor.
  Anyone who must stay on mcp 1.x should stay on 0.2.x, and pin an upper
  bound themselves, because the published 0.2.1 has none.

Fixed

• The dependency on mcp carries an upper bound at all. The previous
  unbounded range is what let a new major reach an unchanged artefact: the
  package did not change, the resolver's answer did.

v0.2.1

Patch release: completes the MCP Registry publish (PyPI ownership marker + metadata fixes). PyPI 0.2.0 remains available.

v0.2.0 — First production-ready release

First production-ready release. Aligns the repository with the Swiss Public Data
MCP portfolio, runs a full MCP best-practice audit, and remediates every finding.

Highlights

• Portfolio alignment — Dockerfile, compose, CI/CD (ci/live/publish),
  server.json for the MCP Registry, CONTRIBUTING/SECURITY/PUBLISHING (EN/DE).
• Hardening — single pooled httpx client via a FastMCP lifespan (SDK-001),
  strict Pydantic argument constraints at the tool boundary (SEC-018), a
  code-layer egress allow-list with no off-host redirects (SEC-021), structured
  JSON logging on stderr (OBS-003), Context-based progress/logging (SDK-003),
  and CORS Mcp-Session-Id exposure for SSE (SDK-004).
• Discovery UX — search_catalog returns match_type + an actionable hint
  on empty results (ARCH-003); get_dataset is the aggregated detail tool, so the
  anchor query resolves in two calls (ARCH-007).
• Supply-chain — tool-definitions.lock.json rug-pull guard verified in CI
  (SEC-022); all tool annotations set the full hint set (ARCH-009).

Audit

Production-ready ✅ — run 2026-07-24T091742-Z-i14y-mcp, catalog hash
091f446b2796…: 36 pass · 0 fail · 5 non-blocking partials · 3 todo. Report
and per-finding docs under audits/.

⚠️ Behaviour change

The SSE / streamable-http transport now defaults to HOST=127.0.0.1 (loopback).
Set HOST=0.0.0.0 for remote/PaaS deployments — the Docker image already does.

Install