René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"feat: support \\ without workspace.yaml mcpProxy config","articleBody":"## Summary\n\nAdd 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:`.\n\nExample target UX:\n\n```bash\nallagents mcp add ediprod https://ediprod.mcp.wtg.zone --proxy\n```\n\nOptionally:\n\n```bash\nallagents mcp add ediprod https://ediprod.mcp.wtg.zone --proxy --client claude,codex,copilot\n```\n\n## Motivation\n\nUpstream `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`:\n\n```yaml\nmcpProxy:\n  clients:\n    - claude\n    - codex\n```\n\nThat 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.\n\nToday the user has to:\n\n1. add the MCP server\n2. edit `workspace.yaml`\n3. add `mcpProxy.clients` or per-server overrides\n4. sync again\n\nFor one-off installs, that is more ceremony than necessary.\n\n## Why this belongs on `mcp add`\n\nI think this should be a flag on `mcp add`, not a separate `mcp proxy` command group.\n\n```bash\nallagents mcp add \u003cname\u003e \u003ccommandOrUrl\u003e --proxy\n```\n\nReasons:\n- proxying is a transport/detail of the server definition, not a separate top-level object\n- it composes naturally with existing flags like `--client`, `--transport`, `--env`, and `--header`\n- it matches user intent: “add this MCP server, but proxy it”\n- it avoids splitting similar workflows across `mcp add` and a separate proxy namespace\n\n## Proposed Behavior\n\n### `mcp add --proxy`\n\nWhen `--proxy` is used with an HTTP server:\n\n- the server should be added normally via `mcp add`\n- the workspace config should record that this server should be proxied for the selected clients\n- the built-in proxy rewrite should be applied during post-mutation sync\n- the proxy metadata file should be created automatically if needed\n\n### Interaction with `--client`\n\nIf `--client` is present:\n\n```bash\nallagents mcp add ediprod https://ediprod.mcp.wtg.zone --proxy --client claude,codex\n```\n\nthen proxying should apply only to those clients.\n\nIf `--client` is omitted, I would expect proxying to apply to all MCP-capable configured clients, same as the rest of `mcp add` behavior.\n\n### Config representation\n\nInternally, this can still persist to `workspace.yaml` via the existing `mcpProxy` structure. The point is not to avoid persistence — it is to avoid requiring the user to hand-edit that structure.\n\nIn other words, this issue is about CLI ergonomics, not changing the config model.\n\n## Acceptance Criteria\n\n- [ ] `allagents mcp add \u003cname\u003e \u003curl\u003e --proxy` works for HTTP MCP servers\n- [ ] `--proxy` automatically enables the existing `mcp-remote` rewrite path\n- [ ] proxy metadata file is created automatically when needed\n- [ ] `--proxy --client claude,codex` scopes proxying to those clients\n- [ ] no manual `workspace.yaml` edit is required for the common case\n- [ ] help/docs explain that this uses the existing `mcp-remote`-based proxy implementation\n\n## Related Context\n\n- Existing MCP subcommand issue: #346\n- Existing proxy implementation already exists in `src/core/mcp-proxy.ts`\n- Current capability is strong, but the CLI path is still more manual than it needs to be\n\n## Example Use Case\n\nEnterprise/internal MCP servers like `ediprod` and `wtgkb` 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.\n","author":{"url":"https://github.com/christso","@type":"Person","name":"christso"},"datePublished":"2026-04-23T04:02:49.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/365/allagents/issues/365"}