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)
// 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:
-
Add the resolved config + origin to DiscoveredMcpServer (and/or McpServer), e.g.
{
name: string;
source: McpServerSource;
enabled: boolean;
// new:
config?: McpServerConfig; // command/args/env | url/headers/type
sourcePath?: string; // absolute path of the declaring file
}
-
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.)
Summary
When a session discovers MCP servers (
mcp.discover/ the sessionMcpServerList), 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)None of these carry:
command/args/envfor stdio, orurl/headers/typefor http/sse;.mcp.json/.github/mcp.jsonthe entry came from), only a coarsesourceenum.mcp.config.enable/disableis 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:
Add the resolved config + origin to
DiscoveredMcpServer(and/orMcpServer), e.g.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.)