René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"feat: support allagents mcp add --proxy 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 internal-api https://mcp.example.com --proxy\n```\n\nOptionally:\n\n```bash\nallagents mcp add internal-api https://mcp.example.com --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 internal-api https://mcp.example.com --proxy --client claude,codex\n```\n\nthen proxying should apply only to those clients.\n\nIf `--client` is omitted, proxying should apply to all MCP-capable configured clients targeted by the command.\n\n### Config persistence rule\n\nThis should persist proxy intent in a way that is scoped to the server being added.\n\nPreferred behavior:\n- `mcp add --proxy` should add a per-server proxy mapping for the new server\n- it should not broaden a workspace-wide proxy rule for unrelated MCP servers unless the user explicitly asked for that behavior elsewhere\n\nIn other words, this issue is about CLI ergonomics, not changing the config model.\n\n## Red / Green Definition\n\n### Red\n\nToday, the following flow is not available as a single CLI-driven workflow:\n\n```bash\nallagents mcp add internal-api https://mcp.example.com --proxy\n```\n\nCurrent state requires manual `workspace.yaml` editing to enable the proxy rewrite.\n\n### Green\n\nAfter this feature lands, the same command should:\n\n```bash\nallagents mcp add internal-api https://mcp.example.com --proxy\n```\n\nand all of the following should be true without manual config edits:\n- the server is added to workspace MCP config\n- proxy intent is persisted for that server\n- proxy metadata file exists if required\n- the synced client MCP config uses the proxied stdio form (`npx ... mcp-remote ...`) instead of the raw HTTP URL for targeted clients\n\n## Manual E2E Gate\n\nBefore this is considered complete, manual E2E verification should be run against a temporary workspace.\n\nSuggested steps:\n\n1. Create a temp workspace with at least one MCP-capable client configured.\n2. Run:\n   ```bash\n   allagents mcp add internal-api https://mcp.example.com --proxy\n   ```\n3. Verify `workspace.yaml` was updated with both:\n   - the MCP server definition\n   - server-scoped proxy intent\n4. Verify the proxy metadata file was created automatically if it did not already exist.\n5. Verify the generated client MCP config uses `npx` + `mcp-remote` stdio config rather than the raw HTTP URL for proxied clients.\n6. Re-run sync/update and verify the result is idempotent.\n7. Run the same scenario with `--client claude,codex` and verify only those clients receive the proxied rewrite.\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- [ ] omitting `--client` applies proxying to all MCP-capable configured clients targeted by the command\n- [ ] no manual `workspace.yaml` edit is required for the common case\n- [ ] proxy persistence is scoped to the added server rather than widening unrelated proxy settings\n- [ ] manual E2E verification is performed before the work is considered done\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 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:03:14.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/366/allagents/issues/366"}