Support overriding the MCP server name in config

[pete-woods]

What does this PR do?

Adds support to set the default server name for your app in config.

It means we'll be able to revert this PR CircleCI-Public/circleci-cli#1631 :)

Checklist

• Tests added or updated
• Docs added or updated

[github-actions]

Review: Support overriding the MCP server name in config

Nicely scoped change — the flag → config → executable precedence is implemented consistently across all three editors, and the test coverage is strong (golden files for help/usage output plus behavioral tests for all three resolution branches). Docs and the ServerNameUsage helper are a good touch.

One design issue

ServerName is wired into enable but not disable, which breaks the enable→disable round-trip.

With Config.ServerName = "my-cli":

• enable writes a server entry named my-cli.
• disable (without --server-name) still derives the name from the executable, doesn't match my-cli, and silently no-ops (⚠️ MCP server "my-cli" does not exist) — leaving the stale entry behind.

Before this PR both commands derived from the executable, so the round-trip was symmetric. Now anyone using the new config must remember to pass --server-name to disable. Recommend threading serverName into disableCommand too (same precedence), across claude/vscode/cursor. Inline comment left on claude/root.go:21.

If leaving disable out is intentional for this PR, a note in the Config.ServerName doc comment (and the ServerName docs section) that disable isn't covered would save users the surprise.

Looks good

• Precedence logic in each enable.go run is correct and readable.
• ServerNameUsage correctly reflects the configured default in --help.
• Build and go test ./test/ pass locally.

Happy to approve once the enable/disable asymmetry is addressed or explicitly documented as out of scope.

[pete-woods]

Happy to approve once the enable/disable asymmetry is addressed or explicitly documented as out of scope.

I don't know how I missed that, PR updated!

[pete-woods]

Okay, have updated the PR again, addressing that feedback

[pete-woods]

Hi @njayp - is there anything else I need to change about this PR? Thanks