No way to ask which MCP servers a deployment actually reaches #776

New issue

Closed

opened 2026-08-14 06:50:01 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-14 06:50:01 +00:00

Member

🤖 Filed by Claude Code on Kai's behalf.

The MCP roster is deployment-owned through SIRENS_ECHO_MCP_ROSTER, so which servers a lane carries is a deploy fact rather than a repository one. There is no way to ask the running process what it actually reached.

logCapabilities emits mcp_servers as a count at boot, which answers how many and not which, and only to whoever is reading logs.

The gap that matters

The roster file names servers. Whether one answered is a different fact, and the two come apart precisely when someone needs to know — a server that is configured and unreachable looks identical to one that was never configured, from outside the process.

Proposal

A /mcps slash command listing each configured server and the tools it advertises, built from the discovered tool set rather than from the file, so the three states stay distinct:

answered, with tools
answered, advertising nothing
configured, did not answer

It needs no new network calls: the supervisor already discovers and caches tools per server, and ToolDefinition already carries Server attribution alongside Unavailable().

Constraints it has to respect

No addresses. An MCP entry holds a URL, transport, and environment map. Those are in-cluster and deployment-owned. The same reasoning that keeps them out of the boot capability log — "a path or a channel id here would grow into an identifier" — keeps them out of a reply. Worth a test rather than a review note.

Ephemeral. Echo's channel carries members who did not ask. Introspection should answer the caller and not become a durable searchable artifact of the tool surface. The refusal paths need the same treatment, or a denied invocation becomes the public event the flag was avoiding.

No job dependency. runCommand currently returns jobs are not enabled before its switch, so every command assumes the job system. Reporting a tool surface is not job work.

🤖 Filed by Claude Code on Kai's behalf.

> 🤖 Filed by Claude Code on Kai's behalf. The MCP roster is deployment-owned through `SIRENS_ECHO_MCP_ROSTER`, so which servers a lane carries is a deploy fact rather than a repository one. There is no way to ask the running process what it actually reached. `logCapabilities` emits `mcp_servers` as a count at boot, which answers how many and not which, and only to whoever is reading logs. ## The gap that matters The roster file names servers. Whether one answered is a different fact, and the two come apart precisely when someone needs to know — a server that is configured and unreachable looks identical to one that was never configured, from outside the process. ## Proposal A `/mcps` slash command listing each configured server and the tools it advertises, built from the discovered tool set rather than from the file, so the three states stay distinct: - answered, with tools - answered, advertising nothing - configured, did not answer It needs no new network calls: the supervisor already discovers and caches tools per server, and `ToolDefinition` already carries `Server` attribution alongside `Unavailable()`. ## Constraints it has to respect **No addresses.** An MCP entry holds a URL, transport, and environment map. Those are in-cluster and deployment-owned. The same reasoning that keeps them out of the boot capability log — "a path or a channel id here would grow into an identifier" — keeps them out of a reply. Worth a test rather than a review note. **Ephemeral.** Echo's channel carries members who did not ask. Introspection should answer the caller and not become a durable searchable artifact of the tool surface. The refusal paths need the same treatment, or a denied invocation becomes the public event the flag was avoiding. **No job dependency.** `runCommand` currently returns `jobs are not enabled` before its switch, so every command assumes the job system. Reporting a tool surface is not job work. > 🤖 Filed by Claude Code on Kai's behalf.

coilyco-ops referenced this issue from a commit

2026-08-14 06:50:20 +00:00

feat(commands): add /mcps, which reports the reachable tool surface

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-14 06:50:43 +00:00

Add /mcps, which reports the reachable tool surface #777