[Bug]: MCP connections_list 'tags' filter returns 0 results — filters deprecated string-array tags instead of connection_tags

Bug Description

The MCP tool connections_list accepts a tags filter, but it always returns 0 results for tags that demonstrably exist — while the equivalent REST call returns them correctly.

The root cause looks like an inconsistent type for the same tags JSON key within gateway/api/mcpserver/tools_connections.go:

So create/update/read all use the key/value connection_tags, but list filters against the legacy string-array field, which is empty on connections tagged through the current API or the webapp.

The net effect for an agent: it reads tags back as a key/value map, then cannot filter by that same value.

Steps to Reproduce

1. Tag a connection with a key/value tag (webapp, REST, or connections_update), e.g. environment=prod-eu.
2. Confirm it round-trips through MCP — connections_get returns it as a map:

// tools/call connections_get {"name": "<connection>"}
"tags": {"environment": "prod-eu"}   // map[string]string

3. Confirm REST filtering works:

curl -sG --data-urlencode 'tag_selector=environment=prod-eu' \
  -H "Authorization: Bearer $HOOP_KEY" \
  https://<gateway>/api/connections
# -> 2 connections

4. Call the MCP tool with the same filter:

// tools/call connections_list
{"tags": ["environment=prod-eu"]}
// -> []

Also tried ["environment:prod-eu"] and bare ["environment"] — all return [].

Passing a string instead of an array is rejected by schema validation, confirming the array type is intended:

validating /properties/tags: type: environment=prod-eu has type "string", want one of "null, array"

Expected Behavior

connections_list should filter on connection_tags (the key/value field that connections_create, connections_update, and connections_get all use), so that a tag read back from a connection can be used as a filter.

Ideally the filter accepts the same selector syntax as the REST tag_selector parameter (key=value, key!=value, multiple constraints ANDed).

Actual Behavior

connections_list returns [] for every key/value tag filter, because it filters against the deprecated string-array tags field rather than connection_tags.

Same gateway, same credential, same tag:

This makes tag-based filtering unusable from MCP. On a gateway with many connections it matters for context size: an unfiltered connections_list on our install returns all 530 connections in a single ~203,000-character response (~50k tokens). subtype and search filters work and are the only practical workarounds, but they can't express organizational grouping.

Version

1.132.0 (self-hosted, OSS license, commit 4e5f7de)

Additional Context

• Verified via direct POST /api/mcp JSON-RPC calls, so this is server-side and not specific to any MCP client.
• connection_tags are populated and correct — verified through both REST and connections_get.
• Suggested fix: change connectionsListInput.Tags to map[string]string (or a selector-string form matching REST's tag_selector), and route it to the connection_tags filter rather than ConnectionFilterOption.Tags.