feat: support allagents mcp add --proxy without workspace.yaml mcpProxy config

[christso]

Summary

Add first-class proxy support to the allagents mcp add workflow so users can opt into mcp-remote directly from the CLI, without manually editing workspace.yaml to add mcpProxy:.

Example target UX:

allagents mcp add internal-api https://mcp.example.com --proxy

Optionally:

allagents mcp add internal-api https://mcp.example.com --proxy --client claude,codex,copilot

Motivation

Upstream allagents now has a dedicated mcp command surface, which is the right direction for MCP-only workflows. However, the current proxy path is still driven by workspace.yaml:

mcpProxy:
  clients:
    - claude
    - codex

That works, but it is not ergonomic for users who just want to add one server through the CLI and have it use the built-in mcp-remote rewrite immediately.

Today the user has to:

1. add the MCP server
2. edit workspace.yaml
3. add mcpProxy.clients or per-server overrides
4. sync again

For one-off installs, that is more ceremony than necessary.

Why this belongs on mcp add

I think this should be a flag on mcp add, not a separate mcp proxy command group.

allagents mcp add <name> <commandOrUrl> --proxy

Reasons:

• proxying is a transport/detail of the server definition, not a separate top-level object
• it composes naturally with existing flags like --client, --transport, --env, and --header
• it matches user intent: “add this MCP server, but proxy it”
• it avoids splitting similar workflows across mcp add and a separate proxy namespace

Proposed Behavior

mcp add --proxy

When --proxy is used with an HTTP server:

• the server should be added normally via mcp add
• the workspace config should record that this server should be proxied for the selected clients
• the built-in proxy rewrite should be applied during post-mutation sync
• the proxy metadata file should be created automatically if needed

Interaction with --client

If --client is present:

allagents mcp add internal-api https://mcp.example.com --proxy --client claude,codex

then proxying should apply only to those clients.

If --client is omitted, proxying should apply to all MCP-capable configured clients targeted by the command.

Config persistence rule

This should persist proxy intent in a way that is scoped to the server being added.

Preferred behavior:

• mcp add --proxy should add a per-server proxy mapping for the new server
• it should not broaden a workspace-wide proxy rule for unrelated MCP servers unless the user explicitly asked for that behavior elsewhere

In other words, this issue is about CLI ergonomics, not changing the config model.

Red / Green Definition

Red

Today, the following flow is not available as a single CLI-driven workflow:

allagents mcp add internal-api https://mcp.example.com --proxy

Current state requires manual workspace.yaml editing to enable the proxy rewrite.

Green

After this feature lands, the same command should:

allagents mcp add internal-api https://mcp.example.com --proxy

and all of the following should be true without manual config edits:

• the server is added to workspace MCP config
• proxy intent is persisted for that server
• proxy metadata file exists if required
• the synced client MCP config uses the proxied stdio form (npx ... mcp-remote ...) instead of the raw HTTP URL for targeted clients

Manual E2E Gate

Before this is considered complete, manual E2E verification should be run against a temporary workspace.

Suggested steps:

1. Create a temp workspace with at least one MCP-capable client configured.
2. Run:

   allagents mcp add internal-api https://mcp.example.com --proxy

3. Verify workspace.yaml was updated with both:
   • the MCP server definition
   • server-scoped proxy intent
4. Verify the proxy metadata file was created automatically if it did not already exist.
5. Verify the generated client MCP config uses npx + mcp-remote stdio config rather than the raw HTTP URL for proxied clients.
6. Re-run sync/update and verify the result is idempotent.
7. Run the same scenario with --client claude,codex and verify only those clients receive the proxied rewrite.

Acceptance Criteria

• allagents mcp add <name> <url> --proxy works for HTTP MCP servers
• --proxy automatically enables the existing mcp-remote rewrite path
• proxy metadata file is created automatically when needed
• --proxy --client claude,codex scopes proxying to those clients
• omitting --client applies proxying to all MCP-capable configured clients targeted by the command
• no manual workspace.yaml edit is required for the common case
• proxy persistence is scoped to the added server rather than widening unrelated proxy settings
• manual E2E verification is performed before the work is considered done
• help/docs explain that this uses the existing mcp-remote-based proxy implementation

Related Context

• Existing MCP subcommand issue: feat: mcp subcommand for managing MCP servers independently #346
• Existing proxy implementation already exists in src/core/mcp-proxy.ts
• Current capability is strong, but the CLI path is still more manual than it needs to be

Example Use Case

Enterprise/internal MCP servers often work best through a local proxy for clients that struggle with HTTP auth or OAuth callback flows. allagents already has the machinery for this via mcp-remote; this request is to expose that path directly in the command users already expect to use.

[christso]

Claiming this. I’m implementing allagents mcp add --proxy by persisting server-scoped proxy intent in workspace.yaml, then verifying the proxied sync path end-to-end with deepwiki and wtgkb test MCPs.