v0.2.0

v0.2.0 — relicensed to MIT, and the server catches up

Two things arrive together, because the public face last shipped at v0.1.0
while the server kept moving: this release relicenses the project and
carries the work of two intervening releases whose notes ship alongside it in
.release-notes/.

Relicensed to MIT

• MIT replaces the Hippocratic License 3.0 (Mass Surveillance module).
  HL3 was inherited from a sibling project it actually fits — a durable
  substrate that holds records about people, where mass surveillance is a live
  hazard and an ethical-source covenant is a real deterrent. This server is a
  read-only Postgres connection layer. Its safety property is enforced by the
  database itself — every query runs in a read-only transaction, and
  restricted mode additionally refuses a superuser connection — not by a
  license clause, and it accumulates nothing about anyone. The covenant
  guarded a door with nothing behind it, while costing adopters an
  ethical-source review to clear. MIT excludes no one and asks nothing beyond
  attribution.

• Package metadata modernized to PEP 639: license = "MIT" plus
  license-files = ["LICENSE"]. The published wheel now carries
  License-Expression: MIT (metadata 2.5) with the license text at
  dist-info/licenses/LICENSE, so tooling reads the terms without parsing
  prose.

• README no longer describes the project as source-available. It is open
  source now, in the ordinary sense.

This is prospective: v0.1.0, and the artifact already on PyPI, were published
under HL3 and keep those terms. Take v0.2.0 or later for MIT.

Server changes since v0.1.0

Both of these came from exercising the server against a real 497k-row table,
and both are described in full in .release-notes/v0.1.1.md and
.release-notes/v0.1.2.md, which ship in this release.

• The privilege probe. A read-only transaction does not block
  COPY ... TO PROGRAM, pg_read_file, lo_export, or
  pg_terminate_backend — those capabilities arrive with the role, not the
  transaction. restricted mode now refuses to start if the connection role
  is a superuser or holds filesystem/program-execution roles, and
  unrestricted mode warns: enabling writes is consent to modify data, not
  consent to read server files or execute programs as the database OS user.
  If you deployed v0.1.0 connected as postgres, this is the release that
  tells you.

• max_bytes now bounds what the model actually receives. The SDK ships
  every result twice — as structured content and pretty-printed into a text
  block — and the text block is what enters the model's context, measurably
  larger than compact JSON. The cap is enforced against the rendered form,
  and the default dropped from 400000 to 50000, because the binding
  constraint is the context window, not the transport. This is a behavior
  change: results that previously came back whole may now truncate, with a
  notice telling the model to add LIMIT, filter, or aggregate. Raise
  PG_MCP_MAX_BYTES if you want the old ceiling.

Packaging

• The source distribution no longer ships version-control internals. The
  v0.1.0 sdist on PyPI contained 51 files of .jj/ operation log and index
  out of 78 — the build walked a colocated working tree whose VCS directory
  its ignore file never named. The sdist now excludes them explicitly. No
  private history was ever involved: this repo is built clean rather than
  forked, so its history contains only what you see. The wheel was never
  affected.

• --version and the MCP handshake now report the real version. The
  version string was a literal in the package's __init__.py, stale since
  v0.1.2, and it feeds both the --version flag and the version this server
  advertises to a client when it connects. If you queried either and got
  0.1.2 from something newer, this is why. It now comes from the installed
  distribution's own metadata.

104 tests (53 unit, 51 integration against real PostgreSQL).

v0.1.0

v0.1.0 — initial release

First public release of Kenning PG MCP: a PostgreSQL MCP server with
hard-pinned dependencies and database-enforced read-only access.

• Built on the MCP Python SDK v2.0.0 (2026-07-28 stateless protocol),
  psycopg 3.3.4, pydantic-settings 2.14.2 — exact == pins with a committed
  uv.lock (resolved 2026-08-03).
• Read-only enforcement is transaction- and role-based; every user statement
  runs through the extended query protocol so PostgreSQL itself rejects
  statement stacking. No SQL text is ever parsed for access control.
• Startup probe verifies writes genuinely fail inside read-only transactions
  and aborts the process otherwise.
• stdio and streamable HTTP transports from one handler set; fetch-side
  result capping with machine-readable truncation notices; honest type
  serialization (numeric as string, bytea as base64 with length).
• Three-layer test suite — unit, real-PostgreSQL integration, and an
  adversarial gauntlet run as a low-privilege role, in which every
  write-bypass attempt must fail at the database.
• Multi-stage Docker image (uv sync --frozen, non-root) as the primary
  distribution artifact.