Better server management in profiles

[bobbyhouse]

What I did

• Add an option for atomic updates of add and remove servers from a profile with docker mcp profile server update --add uri --remove uri
• Add ability to specify server to remove by URI docker mcp server remove --server [uri]

Related issue

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

[chatgpt-codex-connector]

💡 Codex Review

mcp-gateway/pkg/workingset/server.go

Lines 166 to 168 in fc781e1

	removedCount = originalCount - len(filtered)
	workingSet.Servers = filtered
	}

Detect missing removals in UpdateServers

UpdateServers calculates removedCount but never checks whether any servers were actually removed, so docker mcp profile server update --remove … succeeds even when the requested URIs don’t match the profile and still proceeds to add new servers. This breaks the advertised atomic add/remove behavior and differs from RemoveServers, which errors when nothing is removed.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

The base branch was changed.

[cmrigney]

I haven't looked at the code yet, but wanted to provide feedback that I think we should avoid removing servers by URI for a few reasons:

1. I think it's an anti-pattern. Servers are identified by <profile-id>.<server-name>, not by where it came from. If someone is trying to remove by URI, then they're probably trying to use the CLI in a way that wasn't intended or fits with the data model. Adding a server is different, because you do need to specify where to "download" it from. Analogously, when you download a file from a url, you don't delete it by specifying the url again. Instead, you delete it by its file name.
2. It's unreliable. For example, docker://myimage might have the name my-image when added but then a later build has the name other-image when removed. Not only would it not get removed as the user might expect (because there's no match), but it could remove the wrong server.
3. It adds unnecessary overhead of fetching information about the server again, which we already have stored in the profile.