[Feature] Can MCP service management be supported

[lironghai]

Problem

Can MCP service management be supported
This can provide a one-stop solution for skill and MCP management, and currently many skills require cooperation with MCP tools for execution

Proposed Solution

This can provide a one-stop solution for skill and MCP management, and currently many skills require cooperation with MCP tools for execution

Alternatives Considered

No response

Impact

No response

Contract Or SDK Impact

No response

[github-actions]

Issue Triage

• Route: triage/deferred
• Priority: priority/p2 (2.6/5)
• Effort: effort/l (4/5)
• Confidence: 4/5
• Risk: low
• Analysis Mode: rules-only

Why

• Open for 7 days; entering the 2-week closure warm-up window.
• Thread already has follow-up discussion, so backlog pressure is rising.

Next Action

• Keep the issue in the deferred queue and let the 6-hour rescore keep lifting it; it is forced into an active lane by day 10. If it is still open on day 14, treat it as a P0 escalation target under the SLA and prioritize it in the next triage pass.

---

问题分流结果

• 路由: triage/deferred
• 优先级: priority/p2 (2.6/5)
• 修复投入: effort/l (4/5)
• 信息完整度: 4/5
• 风险: 低
• 分析模式: rules-only

原因

• 已打开 7 天，开始进入 2 周闭环预热窗口
• 已有后续讨论，积压压力在上升

下一步

• 将 issue 保留在 deferred 队列，并由 6 小时一次的 rescore 持续抬升；最晚在第 10 天强制进入 active lane。若第 14 天仍未闭环，应按 SLA 视为 P0 升级目标，并在下一次 triage 中重点处理

[dongmucat]

Hi @lironghai, thanks for raising this!

MCP service management is a direction worth discussing. SkillHub today focuses on skill publishing, versioning, and discovery, but as you pointed out, many skills rely on MCP tooling at runtime — which forces users to manage skills and MCPs across two separate systems. That's clearly not the experience we want.

Before we evaluate this feature in depth, I'd like to align on a few questions so the scope doesn't drift:

1. Scope of management: Are you looking for SkillHub to act as an MCP registry (publish / discover / version / permissions), or should it also handle runtime hosting of MCP servers? These are an order of magnitude apart in effort.
2. MCP form factor: Which types are you primarily targeting — remote services (HTTP / SSE), or also local-process MCPs (stdio)?
3. Dependency declaration: Would you like skills to declare MCP dependencies (with version ranges, like a package manifest), or do you also need reverse lookup ("which skills depend on this MCP")?
4. Credentials / secrets: MCPs usually require tokens or API keys. Should SkillHub manage these (which implies encrypted storage and rotation), or do users configure them on their own side?
5. Priority & use case: The issue is currently labeled priority/p3 + triage/deferred. Could you share one or two concrete use cases, or the workaround you're using today? That helps us decide whether to pull it forward.

Feel free to follow up directly in this issue. A design proposal PR is also very welcome — we'll fold it into the next roadmap review. Thanks again for the feedback!

[lironghai]

Hi @lironghai, thanks for raising this!

MCP service management is a direction worth discussing. SkillHub today focuses on skill publishing, versioning, and discovery, but as you pointed out, many skills rely on MCP tooling at runtime — which forces users to manage skills and MCPs across two separate systems. That's clearly not the experience we want.

Before we evaluate this feature in depth, I'd like to align on a few questions so the scope doesn't drift:

1. Scope of management: Are you looking for SkillHub to act as an MCP registry (publish / discover / version / permissions), or should it also handle runtime hosting of MCP servers? These are an order of magnitude apart in effort.
2. MCP form factor: Which types are you primarily targeting — remote services (HTTP / SSE), or also local-process MCPs (stdio)?
3. Dependency declaration: Would you like skills to declare MCP dependencies (with version ranges, like a package manifest), or do you also need reverse lookup ("which skills depend on this MCP")?
4. Credentials / secrets: MCPs usually require tokens or API keys. Should SkillHub manage these (which implies encrypted storage and rotation), or do users configure them on their own side?
5. Priority & use case: The issue is currently labeled priority/p3 + triage/deferred. Could you share one or two concrete use cases, or the workaround you're using today? That helps us decide whether to pull it forward.

Feel free to follow up directly in this issue. A design proposal PR is also very welcome — we'll fold it into the next roadmap review. Thanks again for the feedback!

1. I believe that SkillHub can serve as a gateway for MCP services, serving as the MCP registry for publishing/discovering/version/permission/forwarding
2. I feel that both skill statement MCP dependency (with version range, such as package list) and reverse lookup are necessary, so that the impact range can be clearly known when adjusting skills or MCP
3. Token or API key allows users to configure them themselves
4. We are also selecting the MCP management end, and currently may integrate IBM/mcp-context-forget merge or Samanhappy/mcpchub into the skillhub for managing MCP's external capabilities