mcp-data-platform-v1.70.1

Overview

Fixes a multi-replica cache-coherence bug (#501). On a deployment running more than one replica, configuration changes made through the admin API were applied only to the in-memory state of the replica that handled the request. Every other replica kept serving stale state until it was restarted.

The session broadcaster already propagates the client-facing notifications/tools/list_changed event, but there was no server-side cross-replica signal to reload in-memory state. This release adds that signal.

How it surfaced

On a 2-replica deployment, an operator attached an API catalog to a kind=api connection. The replica that handled the save rebuilt the connection (spec parsed, operations and embeddings built); the other replica never reloaded it. A sticky MCP session pinned to the second replica kept getting api_list_specs and api_list_endpoints returning "no catalog configured," with no error to explain why.

What changed

A cross-replica reload bus is now the server-side counterpart to the client notification path. When an operator changes configuration through the admin API on one replica, that replica reloads locally and publishes a reload event; every other replica receives it and re-materializes the affected in-memory state.

• Dedicated channel. A second postgres LISTEN/NOTIFY broadcaster runs on the configured broadcast channel with a _reload suffix. These internal control-plane events are kept off the client tools/list_changed fan-out, so they are never written to an MCP client's SSE stream. It carries the same per-deployment isolation as the existing channel.
• Per-replica subscriber. Each replica runs a subscriber that re-materializes the affected state when a peer announces a change.
• Self-origin skip. Every event carries the publishing replica's origin id. The replica that handled the write already reloaded synchronously, so it skips its own broadcast and avoids a redundant rebuild.
• Graceful fallback. On a single-replica or database-less deployment the bus uses an in-memory broadcaster, where publish and subscribe are a local no-op. Behavior there is unchanged.

Surfaces propagated across replicas

All four admin-mutable surfaces now stay coherent on every replica:

• API catalog spec edits publish a catalog reload; subscribers rebuild every connection that mounts the catalog.
• Connection (api / mcp) create, update, and delete publish a connection reload; subscribers rebuild that connection from the store, or drop it when the row is gone.
• Persona (authorization) create, update, and delete publish a persona reload; subscribers reconcile the persona registry from the store.
• API key (authentication) create and delete publish an api-key reload; subscribers re-sync the in-memory database-key set via ReplaceHashedKeys, which replaces the full set so a revoked key stops authenticating on peer replicas. This closes a security gap: previously a key revoked on one replica continued to authenticate on the others until restart.

The handler still reloads its local replica synchronously (read-your-writes on the handling replica); the broadcast covers the peers.

Upgrade notes

No configuration changes are required. The reload bus auto-enables when a database is configured and falls back to in-memory (no-op) otherwise.

This removes the prior operational workaround for multi-replica deployments. A kubectl rollout restart after a catalog, connection, persona, or API-key change is no longer needed for peer replicas to pick up the change.

Installation

Homebrew (macOS)

brew install txn2/tap/mcp-data-platform

Claude Code CLI

claude mcp add mcp-data-platform -- mcp-data-platform

Docker

docker pull ghcr.io/txn2/mcp-data-platform:v1.70.1

Verification

All release artifacts are signed with Cosign. Verify with:

cosign verify-blob --bundle mcp-data-platform_1.70.1_linux_amd64.tar.gz.sigstore.json \
  mcp-data-platform_1.70.1_linux_amd64.tar.gz

Full changelog: v1.70.0...v1.70.1