chore: remove collections from the dashboard and API

Merged
AD
2mo ago
+2304-29381

AGE-3365

Summary

Removes the MCP collections feature's UI and API surface. The backing tables survive this PR; a follow-up migration drops them.

Server:

  • Deletes the collections Goa service and its seven /rpc/collections.* endpoints, the service implementation, and its sqlc queries.
  • Deletes the mcp_collection URN type and the five mcp_collection:* audit actions. The audit_log.mcp_collection_event_v1 webhook event stays registered and is marked deprecated: nothing emits it any more, but removing an event type from the catalog breaks every subscriber's event-type list and there is no deprecation path for retiring one yet.
  • Regenerates Goa, the OpenAPI documents, the webhook catalog, and the TypeScript SDK.

Dashboard:

  • Deletes the Collections pages, their route, and the sidebar entry.
  • Deletes the Publishing section from both MCP server settings variants (toolset-backed and mcp_server-backed), which existed only to attach a server to a collection.
  • Deletes the collection group panel from the access grant-rule drawer. Grant rules that selected a whole collection stored individual tool selectors, so they keep working and now render in the tools panel.
  • Drops the Sources "Catalog kind" filter and the Collection origin label on catalog sources — both only ever distinguished collection-backed entries from ordinary ones.
  • Stops rendering the collection audit actions and subject type. Historical audit entries for those actions fall back to the generic renderer, so they read as "created mcp collection" rather than "created collection".

external_mcp_attachments.organization_mcp_collection_registry_id and the three organization_mcp_collection* tables are untouched here, so any existing attachment rows keep resolving. The migration PR nulls the column, drops it along with the tables, and removes the field from the deployments and catalog APIs.

One incidental change: dropping the MCPCollection type freed a name collision in the generated SDK, so Speakeasy renamed the TransportType export on ExternalMCPRemote. The one consumer now types the value off ExternalMCPRemote["transportType"] instead of importing the alias, so a future rename is a non-event.

Motivation

Collections are defunct from a product standpoint — nothing in the product drives users toward them, and advanced plugin features plus the MCP gateway endpoints cover the same ground better. Keeping them costs a service, an audit surface, a set of dashboard pages, and a filter dimension that can only ever hold one value once the feature is unused.

Splitting the removal in two keeps the destructive half separable: this PR is pure code deletion and can be reverted freely, while the migration that drops the data lands on its own and can be reviewed on its own terms.