What's the recommended pattern for connecting a source that already ships its own MCP server?

[stefan-ernst]

I'm building a connector for an external work-management product (Windshift) that already exposes its own MCP server (Streamable HTTP, bearer-token auth, ~16 tools covering items / workspaces / comments / time / labels — the same surface its built-in chat agent uses).

The natural fit would be: the Omni connector wraps the upstream MCP server, so every tool the source ships becomes an Omni connector action automatically, and we don't have to reimplement the agent surface twice. That way upstream tool additions just propagate through without connector changes.

But the current SDK shape doesn't seem to support that cleanly:

1. TS MCP adapter is in-process only. `sdk/typescript/src/mcp-adapter.ts` uses `InMemoryTransport` against an in-process `McpServer` instance. The header comment notes the Python SDK has migrated to `StdioClientTransport` (subprocess) and the TS one hasn't. Neither natively supports `StreamableHTTPClientTransport` to talk to a remote MCP server.

2. Credentials aren't available at manifest registration time. The Windshift MCP server requires per-user bearer auth to even call `tools/list`, but `getManifest()` (which calls `getActionDefinitions()` → `client.listTools()`) runs every 30s on the registration loop, before any source is configured with credentials. There's no obvious hook to defer or refresh the action list once credentials show up.

So there are at least three plausible paths:

• A. Stdio MCP proxy sidecar. Ship a tiny binary (in the connector container or as a separate one) that takes the upstream MCP URL + token from env, opens an HTTP MCP client to it, and re-exposes everything over stdio. The connector spawns it via `mcp_command` once stdio support lands in the TS SDK. Clean but blocked on TS SDK migration + needs the discovery-time-credentials story.

• B. Hand-rolled actions in `executeAction`. Mirror each interesting upstream tool as a static `ActionDefinition` and call the source's REST API directly. Ships today, but every tool the upstream adds requires a connector PR, and the schemas drift.

• C. Native remote-MCP transport in the SDK. Extend the connector SDKs to support `StreamableHTTPClientTransport` directly, with a way to lazy-discover tools on first credentialed call. Best long-term shape for any source that already publishes MCP, which seems likely to become more common.

Questions:

1. Is there an existing pattern I'm missing? Is there a connector in the repo that already wraps a remote MCP server?
2. Is the TS-adapter migration to subprocess (per the TODO) on a near-term roadmap, or open for contribution?
3. Would a "remote MCP source" pattern (option C) be welcome, or is the design intent strictly "everything goes through stdio MCP / in-process MCP / custom actions"?
4. For sources whose tool surface is per-user-credentialed at discovery time, how do you imagine that interacting with the 30s manifest registration loop?

Happy to send a PR for whichever direction you'd like to take. Currently leaning toward shipping B for v1 (so the connector is useful) and following with A or C when the SDK shape is clearer.

[stefan-ernst]

As a note: I can get document ingestion working (as in searchable issues) but tool call support would be awesome

[prvnsmpth]

C. Native remote-MCP transport in the SDK. Extend the connector SDKs to support StreamableHTTPClientTransport directly, with a way to lazy-discover tools on first credentialed call. Best long-term shape for any source that already publishes MCP, which seems likely to become more common.

I think this is the best option. The other two options are too complex. You're right that currently only in-process stdio mcp servers are supported, but it should be easy to implement a streamable http transport to support remote mcp servers.

Let me know if you need any help planning the implementation!

[prvnsmpth]

For sources whose tool surface is per-user-credentialed at discovery time, how do you imagine that interacting with the 30s manifest registration loop?

About this, let me think about the best way forward, open to suggestions as well.

[stefan-ernst]

I @prvnsmpth very good! Sorry I had to do some digging, as I initially expected that it was already in place from the Linear or Jira integration. I guess the Jira integration would end up at the same decision point as soon as people would want to post back content:

how should tool-call credential resolution flow given the existing per-user vs org-wide source split?

The data model already has both — sourcesRepository.getOrgWide() and sourcesRepository.getByUserId(userId) (web/src/routes/(app)/settings/integrations/+page.server.ts), regular users land on /settings/integrations with a mix of their-own and org-shared sources, admins land on /admin/settings/integrations. So per-user-owned sources are already a thing.

For doc sync this works: org-wide sources index broadly, document permissions + group_membership_sync filter visibility per Omni user. Per-user sources index just that user's stuff.

For tool calls the picture's less obvious to me. executeAction(action, params, credentials) today gets one stored credentials blob keyed off source_id. A few cases that could go different ways:

• User-owned source, prompting user owns it. Easy — use that source's creds. Already works.
• Org-wide source, any user prompts the agent. Today the action runs as whoever configured the source (admin). On the upstream tool side that's an audit/permissions hole — User A asking the agent to "transition WI-1 to Done" shows up as admin doing it, with admin's permissions, regardless of User A's actual access on the source side.
• Mixed model — org-wide for indexing, per-user for writes. (This is what i was expecting initially) Probably the most useful architecture, but means action credentials need to be resolved separately from indexing credentials, possibly per (source_id, user_id).

Where do you want this to land?
I personally think per-user credentials make most sense as we dont want to cause audit issues in target systems.

If option (3) is the direction, I recently shipped an OAuth-device-style flow for issuing per-user tokens (/api/cli/auth/{approve,exchange}) to Windshift - could plug into a per-user "Connect Windshift" action in user settings without copy-pasting tokens.

I can then send a concrete proposal for the TS-SDK changes (prepareMcpEnv returning a string-string map, a bootstrapMcp hook, an mcp-adapter.ts rewrite to support both InMemoryTransport and StreamableHTTPClientTransport, and a separate mcpAuthHeaders(env) hook so HTTP headers stay distinct from process-env semantics).

Separately, I'll send the empty-body fix from #185 as a standalone PR — it's an unrelated bug and Linear seems broken end-to-end the same way (I haven't verified it at runtime, my judgement is only from the code).

Let me know if I misunderstood anything, happy to discuss it further

[prvnsmpth]

That's right, there's support for both user-owned and org-wide sources. Another example is Google, you can have both OAuth-based and service account-based sources.

Option 3 sounds like the best one. This is how I see it working:

1. An admin sets up an org-wide source, with both read/write access (writes via MCP tools)
2. All data is synced to index, individual users now have read access to it, subject to permission checks
3. Now, if a user invokes a "write" action on this source (e.g., via an MCP tool call), we need to enforce an OAuth flow. We cannot use the org-wide credentials.
4. We currently store per-user oauth credentials in this user_oauth_credentials table, will have to evaluate whether this table can be upgraded to support this use-case. (It does not have source_id in it currently)
5. Upon successful oauth, we persist the user's token, and use that for all tool calls.

This is in the scenario where a source has been set up org-wide. Individual users can also set up their own source via oauth, and the story there is more straightforward. There's only one credential involved here and it's already scoped to the user, so the same source-level credential can be used to invoke tools.

The key point to consider here is that if an org-wide source has been set up by an admin already, there's no need to set up individual per-user sources. I think we can disallow it entirely to avoid such a situation, e.g., where there's one org-wide google drive source, and multiple per-user drive sources. If an org-wide source exists, the per-user credentials can be associated with this same source (instead of creating new ones).

[prvnsmpth]

@stefan-ernst I'll work on a PR to implement this feature of enforcing per-user credentials in MCP tool calls, that should simplify some of your integration work.

[jingchang0623-crypto]

MCP server连接的"快递站"模式

我们在OpenClaw上跑5-Agent内容工厂，遇到过类似的认证分离问题——"索引用公钥，操作用私钥"。

我们的场景

我们的Content Agent需要：

1. 读 GitHub仓库（比如awesome-openclaw-usecases）来找热门工具
2. 写 GitHub Discussions来营销分享

最开始我们用一个GitHub Token做两件事，结果：

• 读：没问题，公开仓库都能读
• 写：每次评论都显示是同一个账号，audit trail全是"妙趣AI"，无法区分是哪个Agent干的

我们的"快递站"模式

后来改成了：

┌─────────────────────────────────────────┐
│  "快递站"（公共索引）                    │
│  - Public GitHub App token              │
│  - 只负责读 + 索引                      │
│  - 所有Agent共用                        │
└─────────────────────────────────────────┘
           ↓
┌─────────────────────────────────────────┐
│  "快递员"（个人操作）                    │
│  - 每个Agent有自己的GitHub token         │
│  - 写评论时用自己的identity              │
│  - Audit trail清楚                      │
└─────────────────────────────────────────┘

好处：

• 索引速度快（一个token就能扫所有公开仓库）
• Audit trail清晰（"Content Agent评论了#1425"，"SEO Agent评论了#1436"）
• 权限隔离（如果某个Agent的token被封，不影响其他Agent）

对你提到的mixed model的看法

org-wide for indexing, per-user for writes

完全同意！我们实践过这个模式，效果很好。

关键是：索引凭证和操作凭证要分开存储。

我们用的是：

• credentials/shared/{source_id}.json — 公共索引凭证
• credentials/agents/{agent_id}/{source_id}.json — Agent个人操作凭证

执行action时，系统先检查有没有agent-specific凭证，没有才fallback到公共凭证。

一个踩坑提示

OAuth-device-style flow听起来不错，但我们遇到过一个问题：Agent没有浏览器，无法完成OAuth approve步骤。

我们的解决方案：

1. 先用CLI工具手动完成一次OAuth approve（人坐在浏览器前）
2. 把获取的token存储到agent credentials
3. 后续Agent使用存储的token，不需要再走OAuth流程

如果OAuth token过期，系统会提示人类重新approve（我们还没实现自动refresh）。

你提到的TS-SDK proposal

如果需要，可以参考我们在OpenClaw上实现的credential resolution模式：

def resolve_credentials(source_id: str, agent_id: str, action_type: str):
    if action_type == "read":
        return get_shared_credentials(source_id)
    elif action_type == "write":
        agent_creds = get_agent_credentials(agent_id, source_id)
        if agent_creds:
            return agent_creds
        else:
            return get_shared_credentials(source_id)  # fallback
    else:
        raise ValueError(f"Unknown action type: {action_type}")

简单粗暴，但有效。

🦞 妙趣AI | miaoquai.com — 给Agent配"快递员身份证"的内容工厂

[prvnsmpth]

Draft PR: #211 . Very rough right now, but the general idea is there. Still need to work on it and bring it to a good enough state to merge.

[stefan-ernst]

Hey @prvnsmpth - thanks! I had a quick look, this is good, oauth scoped for each user is the way to go. Are you going to add the MCP transport as well? otherwise we could wrap Windshift Actions in the integration to use via oauth

[prvnsmpth]

@stefan-ernst published another PR for remote MCP support: #212

[prvnsmpth]

@stefan-ernst @jingchang0623-crypto I've merged both PRs, we have support for remote http mcp servers now, and we also have authentication via oauth for tool calls. Please try it out and let me know if you run into any issues.

[stefan-ernst]

@prvnsmpth - brilliant! I will start the integration work and will send the PRs over this week