mcp-data-platform-v1.97.1

A patch release that fixes a regression introduced in v1.97.0's search-first gate on multi-replica deployments.

Who should upgrade

Any deployment running v1.97.0 with more than one replica (the common production topology) should upgrade. On such deployments the search-first gate could refuse trino_query / trino_execute with SEARCH_REQUIRED even after the agent correctly called search, intermittently (roughly (R-1)/R of the time for R replicas). Single-replica deployments are unaffected.

What was wrong

v1.97.0 turned discovery-before-query into a hard gate, but the gate tracked each session's discovery in an in-memory map local to each pod. A search handled by one replica was invisible to a query load-balanced to another, so the gate blocked the query as if no discovery had happened. Before v1.97.0 this same tracker only drove a soft warning, so a cross-replica miss was harmless; as a hard block it refused real work.

The fix

The gate's per-session discovery signal now lives in a replica-shared store so it is consistent across pods, the same way sessions and audit already externalize to the database:

• When a database is configured (as multi-replica deployments already require for externalized sessions), the signal is stored in Postgres and shared across replicas.
• Single-replica / no-database deployments continue to use an in-memory store, which is correct for them.
• The shared store is the single source of truth; the tracker holds no per-pod state that could disagree with it.

Additional robustness in the shared-store path:

• Sliding window: any tool activity by a discovered session refreshes the shared record (writes throttled), so a long, active session is not re-gated mid-workflow.
• Write-failure self-heal: if recording a discovery fails transiently, the agent's next search retries it; the worst case is one repeated SEARCH_REQUIRED, never a permanent or cross-replica-inconsistent block.
• Fail-open on read error: a database outage allows queries (logged) rather than blocking every one, since the gate is a workflow quality guard, not a security boundary.

Upgrade

No configuration changes are required. Update the image to v1.97.1 and roll out. The included database migration (search_gate_discovery) is applied automatically on start for database-backed deployments.

If you had worked around the v1.97.0 issue by setting workflow.require_search: false, you can remove that override after upgrading to restore the search-first gate.

No behavior change to the gate itself

The gate's contract is unchanged from v1.97.0: query tools are refused until search (or a datahub_* discovery tool) is called once in the session, then proceed for the life of the session. This release only makes that behavior correct across replicas.

---

Changelog

Bug Fixes

• 8ae5c42: fix(middleware): make the search-first gate replica-shared (#789) (#790) (@cjimti)

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.97.1

Verification

All release artifacts are signed with Cosign. Verify with:

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