mcp-data-platform-v1.98.2

Highlights

A focused patch over v1.98.0 that fixes an unbounded-latency bug in the search fan-out. Default-on and backward-compatible: no configuration or migration is required to upgrade.

search no longer stalls on a single slow source (#794)

The search fan-out had no server-side timeout anywhere on its path (the tool handler, the router, the fan-out, the individual providers, or the intent-embedding step). It queries every knowledge source (catalog, memory, insights, context documents, endpoints, connections, and the rest) concurrently, but it awaited all of them with no per-provider deadline, so a search was only as fast as its single slowest source. One lagging provider (a slow catalog index, an unreachable embedder, a stalled database) held the whole search until the MCP client's own call timeout fired, surfacing to the user as a generic "operation timed out."

Each provider arm, and the intent-embedding call, is now bounded by a per-provider deadline (default 5s). A slow source is canceled at the deadline and reported as its own error while the remaining sources still return, so a healthy search completes promptly with partial results instead of hanging on one bad arm. Because the arms run concurrently, total fan-out latency is now bounded to roughly the per-provider timeout.

This behavior was present since search was built; it shipped in v1.98.0 and is corrected here.

Configuration (optional; the 5s default needs no config):

knowledge:
  search_provider_timeout: 5s   # per-provider fan-out deadline; a negative value disables the bound

• enabled behavior: on by default at 5s. Set a longer value for deployments with legitimately slow sources, or a negative value to restore the previous unbounded behavior (a search then waits for its slowest provider).

Compatibility. No action required. The only behavioral change is that a provider slower than the timeout now drops out of a search (with the fast sources still returning) rather than stalling the whole call. Searches that were already healthy are unaffected. The fan-out already tolerated a provider erroring; this adds the same tolerance for a provider being slow.

Known limitation and follow-up

This release bounds the latency but does not yet improve how a timed-out source is attributed:

• A timed-out provider is logged by name, but not distinctly from a functional error, and there is no metric, so there is no dashboard yet for which sources are chronically slow.
• On a partial-success search, a source that timed out is dropped silently: it does not appear in the results or the coverage summary, so an agent cannot tell "this source had nothing" from "this source timed out."

A follow-up will add a distinct timeout log, a per-provider search metric (knowledge_provider_search_total{provider,outcome}), and a degraded_sources field surfaced to the agent. These were deliberately left out to keep this patch focused on the latency fix.

Changelog

Bug Fixes

• fe9865d: fix(knowledge): bound the search fan-out with a per-provider timeout (#794) (@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.98.2

Verification

All release artifacts are signed with Cosign. Verify with:

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