feat(agents): expose per-agent MCP / connector wiring in UI and CLI

[ykbryan]

Summary

Agents have an mcp_config field in the data model, but workspace owners cannot set it from outside the Multica server. As a result, agents that depend on MCP-served tooling (Gmail, Google Calendar, Google Chat, Notion, Slack, etc.) cannot be wired without backend access. Ship a setter on both UI and CLI.

Motivation

In our workspace we built an Inbox Manager agent with a workday autopilot to sweep Gmail / Calendar / Chat. The agent code works exactly as specified. But its mcp_config is null and there is no documented way for a workspace owner to set it. The agent currently logs "all three connectors are not wired in this environment" each run and exits cleanly without doing useful work. The autopilot is paused indefinitely because of this gap.

This is almost certainly hitting other workspaces silently — anyone trying to build a connector-driven agent today is stuck.

Evidence — the field exists, the setter does not

• Agent JSON returned by multica agent get: mcp_config: null, mcp_config_redacted: false.
• Daemon binary contains json:"mcp_config,omitempty" (the Go struct field on the Agent type).
• Daemon binary contains --mcp-config and --strict-mcp-config (it passes these to claude on spawn — proving Multica already constructs an mcp config when one is configured).
• multica agent update --help exposes --custom-args / --custom-env(-file/-stdin) / --runtime-config / --runtime-id / --model / --instructions / --description / --max-concurrent-tasks / --name / --status / --visibility / --output. No --mcp-config. No multica mcp subcommand. No multica connector subcommand.
• Multica Desktop v0.2.24 (latest as of writing): the agent detail screen exposes tabs Activity / Instructions / Skills / Environment / Custom Args. No Connectors / MCPs / Integrations panel anywhere.
• Workspace settings: no MCP / connector setter either.

User stories

• As a workspace owner, I can open an agent in Multica Desktop, see a "Connectors" tab, and attach Gmail / Calendar / Chat / etc. via OAuth or static config.
• As a workspace owner, I can also wire MCPs via CLI for scripted / reproducible setups: multica agent update <id> --mcp-config-file ~/path/config.json, mirroring the existing --custom-env-file pattern for secrets.
• As an agent author building an autopilot, I can verify (via multica agent get <id> --output json) that the connectors are attached before the autopilot fires.

UI scope

• New tab on the agent detail screen, labeled "Connectors" (or "MCPs"), positioned between "Environment" and "Custom Args".
• The tab lists available connectors from the workspace's connector catalog. Each row: name, status (connected / not connected / auth-required), an "Attach" / "Detach" button.
• For OAuth connectors (Google, Notion, Slack), clicking "Attach" launches the OAuth flow scoped to the agent. Tokens are stored in the agent's mcp_config server-side, redacted from API responses (set mcp_config_redacted: true when populated).
• For static-config MCPs (local stdio servers), the row exposes a JSON editor for command, args, env.

CLI scope

• multica agent update <id> --mcp-config-file <path> — read JSON from file (mode 0600 expected).
• multica agent update <id> --mcp-config-stdin — read JSON from stdin (matches the pattern for --custom-env-stdin).
• JSON schema mirrors Claude's standard MCP config: {"mcpServers": {"<name>": {"command": "...", "args": [...], "env": {...}, "url": "..."}}}.
• For OAuth connectors, document a parallel multica agent connector attach <agent-id> <connector-name> subcommand that launches the OAuth flow.
• multica agent get <id> --output json should return mcp_config_redacted: true when set, with the actual mcp_config replaced by <redacted>.

Security

• Secrets in mcp_config (tokens, command args containing creds) MUST be treated like custom_env: never logged, redacted in API responses, only readable by workspace admins.
• The daemon already passes --strict-mcp-config to claude on spawn; preserve that.

Tests

• Unit: agent update with --mcp-config-file writes the field; agent get returns redacted form.
• Integration: spawn an agent with a fixture mcp_config containing a local stdio echo server; verify claude receives --mcp-config <path> with the right content.
• E2E: Multica Desktop attach Gmail flow → daemon spawns claude → claude has Gmail tools available.

Out of scope (separate issues if wanted)

• Connector catalog / marketplace UX (this assumes there is already a list of connectors to attach).
• Workspace-level default MCPs that all agents inherit (worth doing, but a different change).
• MCP server hosting / lifecycle (we don't run them; we just point claude at them).

Verifiable success

1. Workspace owner can attach Gmail to an agent via UI or CLI without backend access.
2. multica agent get <id> --output json shows mcp_config_redacted: true after attachment.
3. Daemon spawns claude with --mcp-config <path> pointing at a file that contains the right mcpServers entry.
4. Pre-existing agents with mcp_config: null continue to work unchanged.

---

Filed by the Multica AI workspace lead agent on behalf of @ykbryan. Happy to split into UI and CLI sub-PRs if that helps review.

[feifeigood]

+1, this is blocking our use case.

[Bohan-J]

@ykbryan good news — the UI half of this shipped yesterday 🎉

You can now set mcp_config on each agent from a dedicated MCP config tab on the agent detail page (PR #3419). Workspace owners no longer need backend access for the use case you described (Inbox Manager wiring Gmail / Calendar / Chat / Notion / Slack via MCP).

Plumbing-wise, the per-agent mcp_config is now wired through 6 runtimes: Claude Code, Codex, Hermes, Kimi, Kiro, OpenClaw.

The CLI-side --mcp-config flag (for power users / scripted setups) is still tracked separately in #3364. Leaving this issue open until the CLI half lands too, then we'll close — happy to flip that if you'd rather we close this one now and let #3364 own the CLI piece.

[kobeng]

@Bohan-J
commit cf4a93a (HEAD -> main, origin/main, origin/HEAD)
Author: Bohan Jiang 52446949+Bohan-J@users.noreply.github.com
Date: Fri May 29 17:30:07 2026 +0800

我的代码最新是这个，但是我运行make selfhost-build ，前端的agent页面没有mcp的配置。

如何搞？

[kobeng]

@Bohan-J commit cf4a93a (HEAD -> main, origin/main, origin/HEAD) Author: Bohan Jiang 52446949+Bohan-J@users.noreply.github.com Date: Fri May 29 17:30:07 2026 +0800

我的代码最新是这个，但是我运行make selfhost-build ，前端的agent页面没有mcp的配置。

如何搞？

前端支持列表还没同步，packages/core/agents/mcp-support.ts 里只有：

["claude", "codex", "openclaw"]

哈哈

[multica-eve]

@kobeng 你说得对，这里确实是前端 allowlist 漏同步了：后端已经把 mcp_config 接到了 Hermes / Kimi / Kiro，但 packages/core/agents/mcp-support.ts 还只放了 claude / codex / openclaw，所以这些 runtime 的 agent 页面会把 MCP tab 隐藏掉。

已在 #3534 修复并合入 main：补上了 hermes / kimi / kiro，也加了 tab 可见性测试覆盖 6 个已支持 runtime。你拉一下最新 main（merge commit eda2150a 之后）再跑 make selfhost-build 应该就能看到。

如果你用的是 Claude / Codex / OpenClaw 但还是看不到 MCP tab，再贴一下这个 agent 绑定的 runtime provider，我们继续查构建产物或 runtime 数据。

[multica-eve]

感谢你指出 MCP 配置虽然存在但缺少可操作入口的问题。当前版本已同时提供每个 Agent 的 MCP 配置界面和 CLI 的 --mcp-config 输入方式，并已接入受支持的运行时。因此该需求已完成，现关闭。