MCP discovery exposes no launch config or source path — blocks viewing/editing discovered servers
- 主要言語
- Java
- スター
- 10.5k
- フォーク
- 1.5k
- 平均マージ
- 1日 14時間
- マージ済み PR(30日)
- 129
説明
## Summary
When a session discovers MCP servers (`mcp.discover` / the session `McpServerList`), the returned shapes expose only **identity and status** — not the **resolved launch config** (command/args/url/env/headers) nor the **origin file path** of the declaration. This makes it impossible for an SDK consumer to (a) show *where* a discovered server came from, or (b) offer **edit / override** of a discovered workspace/plugin server, because the consumer never receives the config it would need to display or round-trip.
## Current shapes (from `dist/generated/rpc.d.ts` / `session-events.d.ts`, beta.9)
```ts
// DiscoveredMcpServer (rpc.d.ts ~2657)
{ name: string; type?: string; source: McpServerSource; enabled: boolean }
// McpServer (rpc.d.ts ~4148)
{ name: string; status: string; source?: McpServerSource; error?: string }
// McpServerSource (session-events.d.ts)
type McpServerSource = "user" | "workspace" | "plugin" | "builtin";
```
None of these carry:
- the resolved **launch configuration** — `command` / `args` / `env` for stdio, or `url` / `headers` / `type` for http/sse;
- the **origin file path** (e.g. which `.mcp.json` / `.github/mcp.json` the entry came from), only a coarse `source` enum.
`mcp.config.enable/disable` is enough to toggle a discovered server (and persists — thank you), but **viewing and editing** a discovered server's definition is not possible from the SDK surface.
## Ask
Extend the discovery surface so consumers can render and edit discovered servers. Either is fine:
1. Add the resolved config + origin to `DiscoveredMcpServer` (and/or `McpServer`), e.g.
```ts
{
name: string;
source: McpServerSource;
enabled: boolean;
// new:
config?: McpServerConfig; // command/args/env | url/headers/type
sourcePath?: string; // absolute path of the declaring file
}
```
2. Or add a dedicated rpc, e.g. `mcp.config.get({ name })` → resolved config + origin path, so consumers can fetch on demand.
Either unlocks: showing the source file in a server detail view, and an **edit/override** affordance for discovered workspace/plugin servers (today only `user`-source servers we wrote ourselves can be edited, because we hold their config; discovered ones are opaque).
## Context / why
We're a desktop UI (Dafman) over the Copilot agent. Users expect to see where a discovered MCP server is defined and to tweak its args/env without hand-editing JSON files they may not know the location of. Toggle persistence already works; this is the remaining gap for a full MCP management UI.
(Filed from downstream tracking issue AsafMah/dafman#9. Happy to provide a repro or test against a beta.)
コントリビューションガイド
調査の方向性
dist/generated/rpc.d.ts と session-events.d.ts を読み、続いて mcp.discover と session McpServerList の形状を mcp.config.enable/disable と併せて追跡します。discovery のレスポンスと、新しい mcp.config.get RPC のどちらが、解決済みの stdio または HTTP/SSE 設定と、それを宣言しているファイルのパスをより適切に公開できるかを判断します。完了条件は、利用側が出所を確認し、検出されたサーバーを編集または上書きできることです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- typescript
- 領域
- api
- issue の種類
- 機能追加
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 48/100