Adding catalog_source with OCI reference to list servers response

[cutecatfann]

What I did

• Adds catalog_source property to each server returned in the docker mcp profile show {profileId} response (and docker mcp server ls)
• The field contains the OCI catalog reference (like docker.io/mcp/docker-mcp-catalog:latest) when a server was added from a catalog, and is omitted when the server was added directly
• This enables the UI to distinguish server origins for search and categorization

New CatalogSource field added to both db.Server and workingset.Server structs, threaded through:

• mapCatalogServersToWorkingSetServers (source of truth, maps from db.CatalogServer.CatalogRef)
• NewFromDb / ToDb (DB roundtrip)

No schema migration required, the servers column stores JSON and the new field uses omitempty, so existing rows deserialize cleanly with an empty value.

Direct-add paths (docker://, https://, file://) leave the field empty. Only the catalog:// resolution path populates it.

Test plan

• TestShowWithCatalogSource, verifies JSON and YAML output include catalog_source for catalog-sourced servers and omit it for directly-added servers
• TestAddServersFromCatalog, new assertions verify CatalogSource is set correctly for both image and remote server types added from catalogs
• All existing tests pass

Manual testing

% docker mcp profile show test_catalog_source --format json
MCP governance enabled, policy evaluation active
{
  "version": 1,
  "id": "test_catalog_source",
  "name": "test-catalog-source",
  "servers": [
    {
      "type": "image",
      "secrets": "default",
      "tools": null,
      "image": "mcp/github@sha256:89fd71b6f2dd098de0d7517c1899b7fe90590d3193e253991d61a800b041bfd4",
      "catalog_source": "mcp/docker-mcp-catalog:latest",
      "snapshot": {
        "server": {
          "name": "github",
          "type": "server",
          "image": "mcp/github@sha256:89fd71b6f2dd098de0d7517c1899b7fe90590d3193e253991d61a800b041bfd4",
          "description": "Tools for interacting with the GitHub API, enabling file operations, repository management, search functionality, and more.",
          "title": "GitHub (Archived)",
          "icon": "https://avatars.githubusercontent.com/u/182288589?s=200\u0026v=4",
          "readme": "http://desktop.docker.com/mcp/catalog/v3/readme/github.md",
          "remote": {},
          "secrets": [
            {
              "name": "github.personal_access_token",
              "env": "GITHUB_PERSONAL_ACCESS_TOKEN"
            }
          ],

% docker mcp profile show test_catalog_source --format yaml
MCP governance enabled, policy evaluation active
version: 1
id: test_catalog_source
name: test-catalog-source
servers:
    - type: image
      secrets: default
      image: mcp/github@sha256:89fd71b6f2dd098de0d7517c1899b7fe90590d3193e253991d61a800b041bfd4
      catalog_source: mcp/docker-mcp-catalog:latest
      snapshot:
        server:
            name: github
            type: server
            image: mcp/github@sha256:89fd71b6f2dd098de0d7517c1899b7fe90590d3193e253991d61a800b041bfd4
            description: Tools for interacting with the GitHub API, enabling file operations, repository management, search functionality, and more.
            title: GitHub (Archived)
            icon: https://avatars.githubusercontent.com/u/182288589?s=200&v=4
            readme: http://desktop.docker.com/mcp/catalog/v3/readme/github.md
            remote: {}
            secrets:
                - name: github.personal_access_token
                  env: GITHUB_PERSONAL_ACCESS_TOKEN

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[austin5456]

Though before we merge this in, I know I called it catalogSource but since it's already existing as ref / catalogRef I'm wondering if we should keep it consistent

[cutecatfann]

I feel like catalogRef is somewhat less descriptive in this case. However, not opposed to changing at all!

[austin5456]

I feel like catalogRef is somewhat less descriptive in this case

I completely agree, but I've seen it be used in other commands as ref 😞 ( and I'd be consuming those too )
I'll leave it up to you, I just find it becomes confusing later down the road if you have different names for the same upstream reference

[cutecatfann]

Agreed, I think it does become confusing. I'll go ahead and change it, and just leave a comment that it actually means catalog_source

[austin5456]

I was curious why it wasn't using source as a name from the get go since imo it makes sense, looks like source already exists and maps to something else??


user:cli?? 😅 I guess this is execution source?

[cutecatfann]

That is so confusing....