Connector Gateway: correct inaccurate claims and stale API spec #1177

Part of #1175.

Public pages that contradict the product's current behavior.

Platform landing page credits vMCP features to the Connector Gateway

The Connector Gateway feature table in docs/platform/index.mdx (around line 195) lists "Build composite tools", "Customize and filter tools and descriptions", and "Reduce context bloat and token usage". Those are Virtual MCP Server (vMCP) features. The gateway doesn't configure composite tools, the optimizer, or tool filtering, and docs/connector-gateway/index.mdx presents them as reasons to choose vMCP instead.

• Replace these rows with actual gateway features, such as per-user connector access, credentials brokered on the user's behalf, identity-provider SSO, and group- or policy-based access.

Published Connector Gateway API spec is stale

static/api-specs/connector-gateway-api.json includes four per-user connector-config routes that are retired and always return 501 Not Implemented:

• GET /v1/users/me/gateway/connectors
• GET/PUT/DELETE /v1/users/me/gateway/connectors/{connector_id}

Per-user enablement now lives on the Enterprise Manager's /v1/me/connections routes. The published file has also drifted from the upstream enterprise/connector-gateway/docs/openapi/swagger.json.

• Regenerate the spec from upstream, or remove the retired routes
• Update the Connector Gateway blurb in api-reference.mdx ("covers connector enablement and per-user authorization state") to match what remains, and point readers to /v1/me/connections
• Consider adding this spec to the release-sync automation so it doesn't drift again

Discovery isn't automatic

docs/connector-gateway/connectors.mdx says discovery "picks up MCP servers running in your cluster automatically." In fact, discovery scans live MCPServer objects and lists them as candidates, each showing whether a connector already uses its endpoint. An administrator admits each one, and nothing is stored until then.

• Reword this and describe the admit flow

Connector access isn't only directory groups

docs/platform/concepts/two-group-models.mdx and connectors.mdx say connector access is decided by directory groups. Each connector has a ConnectorPolicy in structured or Cedar mode. Cedar documents can match UserGroup membership or custom OIDC claims (for example principal.claim_department), and the directory evaluates both modes.

• Correct the group-models table and prose. The full policy docs are tracked in Connector Gateway: document connector auth types and policies #1178.