Correct Connector Gateway claims and stale API spec

[tgrunnagle]

Description

Fixes public Connector Gateway pages that contradicted current product behavior, and the stale published API spec.

Platform landing page (docs/platform/index.mdx)

The Connector Gateway feature table listed composite tools, tool filtering, and context-bloat reduction, which are vMCP features. Replaced them with gateway features: per-user connector access with directory groups or Cedar policies, credentials brokered on each user's behalf, and cluster discovery.

Connector Gateway API spec

• static/api-specs/connector-gateway-api.json is now a byte-for-byte copy of upstream enterprise/connector-gateway/docs/openapi/swagger.json. That drops the four retired per-user connector-config routes (GET /v1/users/me/gateway/connectors and GET/PUT/DELETE .../connectors/{connector_id}) and their schemas.
• api-reference.mdx: the blurb now describes what remains (the caller's gateway view, connection status, connect flow, tools) and points to the Enterprise Manager's /v1/me/connections routes for enabling connectors.
• .github/upstream-projects.yaml: added the spec as a source: asset on the stacklok-enterprise-platform project, matching how its CRDs are sourced. Tested with sync-assets.mjs --clone against a local clone. Since that project has no version: pin yet, the workflow won't trigger on its own until the platform ships releases.

Discovery (connectors.mdx)

Replaced "picks up MCP servers running in your cluster automatically" with the actual flow. Add connector opens a chooser (Import from registry, Discover in Kubernetes, Configure manually). Discovery lists every MCPServer as a candidate, marks ones already Already added as a connector, and registers nothing until the admin chooses Add to catalog. Admitted servers become drafts with no backend auth, which publish on first save.

Connector access (connectors.mdx, two-group-models.mdx, plus one-line fixes in connector-gateway/index.mdx and enterprise-directory/index.mdx)

Connector access was described as directory-groups only. The pages now explain the structured and Cedar policy modes, that Cedar documents can match UserGroup membership or principal.claim_* token claims, and that the console doesn't edit Cedar-mode policies (it shows a notice and disables group editing). The group-models table splits connector access by mode, and that page has a note that Cedar-mode policies are API-only. Full policy docs are left to #1178.

Verification

Checked against stacklok-enterprise-platform origin/main:

• Discovery: discover-connectors-dialog.tsx, add-connector-dialog.tsx, admitDiscoveredServers in connectors-admin/actions.ts, and discovered_server_service.go
• Policy modes: docs/customer/migrations/connector-policy-directory-evaluation.md, directory/app/claims.go (the claim_ prefix), and access-tab.tsx (Cedar-managed notice)
• npm run build passes, and Prettier and ESLint are clean on the changed files

Type of change

• Documentation update

Related issues/PRs

Closes #1177 (part of #1175). Follows #1180.

Submitter checklist

Content and formatting

• I have reviewed the content for technical accuracy
• I have reviewed the content for spelling, grammar, and style

Reviewer checklist

Content

• I have reviewed the content for technical accuracy
• I have reviewed the content for spelling, grammar, and style

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs-website	Ready	Preview	Oct 6, 2026 3:33pm UTC

[danbarr]

Approving from an editorial/IA POV; technical updates could use peer review.

The base branch was changed.

[danbarr]

Reviewed editorially as part of the seven-PR stack, including the assembled result at #1208 (a9c7827). My earlier editorial/IA assessment still stands: correcting the Connector Gateway feature claims and explaining the real discovery and policy behavior are useful improvements.

I also verified that the published Connector Gateway API spec is a byte-for-byte match for the upstream file at the cited e3da43246 revision. I have no additional editorial findings specific to this PR. This is not a blanket technical validation of the Helm deployment instructions; I did not run them against a live cluster.

The remaining page-level findings are on their owning PRs, with the combined navigation and reader-journey assessment on #1208.

[danbarr]

Approved from an editorial and information-architecture perspective. The findings from the stack review are addressed in the assembled result: administrator/owner audience, coherent navigation and credential-guide ownership, canonical access instructions, explicit API-only authentication, qualified usage reporting, and lowercase experience descriptions in prose. This approval does not assert live end-to-end validation of the deployment or examples.