mcp-data-platform-v1.67.3

What's fixed

Persona editor's Connections tab now shows real connection names

The persona editor was listing toolkits instead of connections. An apigateway instance configured with multiple upstream connections appeared as a single entry (e.g. api) in the Connections tab, so connection-specific allow patterns matched nothing in the live preview and the counter showed 0 allowed even though runtime authorization worked correctly.

Root cause: pkg/admin/system.go:listConnections iterated ToolkitRegistry.All() and emitted one entry per toolkit, ignoring toolkit.ConnectionLister. The parallel handler pkg/admin/connection_handler.go:collectLiveConnections (used by the admin Connections page) already expanded multi-connection toolkits correctly; the /connections endpoint used by the persona editor did not.

Fix: when a toolkit implements toolkit.ConnectionLister, emit one connectionInfo per element of ListConnections() with Name and Connection set to the connection name. Single-connection toolkits are unchanged.

Why runtime authorization was correct anyway

pkg/persona/filter.go:IsConnectionAllowed is invoked at tool-call time with the connection name resolved by the toolkit at that moment, so a persona with allow_connections: [salesforce] correctly authorized calls all along. The bug was purely UI-visible: the editor's "0 allowed" counter, the per-item resolution trace, and the wildcard preview were all computed against the wrong set of items, leaving users unable to tell whether their patterns were correct without testing them in production.

Wire-shape change

GET /api/v1/admin/connections response for a registry with a multi-connection toolkit:

Before (one entry per toolkit):

{"connections": [
  {"kind": "api", "name": "apigateway", "connection": "apigateway",
   "tools": ["api_invoke_endpoint", ...], "hidden_tools": []}
]}

After (one entry per real connection):

{"connections": [
  {"kind": "api", "name": "salesforce", "connection": "salesforce",
   "tools": ["api_invoke_endpoint", ...], "hidden_tools": []},
  {"kind": "api", "name": "stripe", "connection": "stripe",
   "tools": ["api_invoke_endpoint", ...], "hidden_tools": []},
  ...
]}

The connectionInfo JSON shape itself is unchanged (same field names, same types). Only the set of entries returned changes. Single-connection toolkits emit exactly the same payload as before.

Edge case

A multi-connection toolkit whose ListConnections() returns an empty slice (apigateway instance registered but with no upstream connections configured yet) now contributes zero entries to the response, where before it contributed one toolkit-level placeholder. This matches the existing behavior of collectLiveConnections used by the admin Connections page, and reflects reality: there is nothing to authorize against until at least one real connection exists.

Upgrade impact

No breaking changes.

• Existing allow_connections and deny_connections patterns in persona YAML keep working because the runtime authorization path was already correct.
• The connectionInfo JSON shape is unchanged (same fields, same types).
• TypeScript ConnectionInfo types in the UI already declared the per-connection shape; the runtime now matches what the types already claimed.
• After upgrading, refresh the persona editor: each apigateway / multi-catalog connection now appears as its own row under its toolkit's group, and existing allow / deny patterns will resolve correctly in the live preview without any persona changes.

Changelog

Bug Fixes

• 6bab1a3: fix(admin): expand multi-connection toolkits in /connections so persona editor shows real connection names (#483) (@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.67.3

Verification

All release artifacts are signed with Cosign. Verify with:

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