Description
Fixed in #245 (issue #229): when a CWD-discovered `./mcpls.toml` is ignored because it's untrusted, mcpls logs a `tracing::warn!` naming the ignored path. This is the only signal that the security gate fired.
stderr output from an MCP server is typically swallowed by MCP clients (Claude Desktop, IDE integrations, etc.) — it isn't surfaced to the AI agent or the human using it. In practice, a user/agent who expected their project-local `mcpls.toml` to be loaded (e.g. one configuring per-tool routing per #228, or custom LSP servers) will see mcpls silently fall back to built-in heuristics with no visible indication why.
Expected Behavior
The "project-local config was ignored, pass --trust-project-config to opt in" notice should also be surfaced in-band, via a channel an MCP client/agent actually reads — most likely `ServerInfo.instructions` (`crates/mcpls-core/src/mcp/server.rs`, `McplsServer::get_info`), so an agent inspecting server info can notice and either report it to the user or pass the flag if authorized.
Actual Behavior
Only a `tracing::warn!` to stderr, generally invisible to the calling agent.
Notes
This requires threading "was a project-local config ignored" state from `ServerConfig::load_with_trust` through to `McplsServer::get_info`, which currently has zero coupling to config-load history — new plumbing with its own test story, which is why it was deferred out of #245 rather than bolted on right before merge.
Environment
Logs / Evidence
Flagged by the adversarial critique pass and confirmed by code review during #245: "stderr is swallowed by MCP clients, so agents get silent degradation of exactly the `./mcpls.toml` where #228's per-tool routing lives." Reviewer recommendation: file as P2 follow-up rather than block the #229 fix on it, since the security property itself is already closed and verified independently of this visibility gap.
Description
Fixed in #245 (issue #229): when a CWD-discovered `./mcpls.toml` is ignored because it's untrusted, mcpls logs a `tracing::warn!` naming the ignored path. This is the only signal that the security gate fired.
stderr output from an MCP server is typically swallowed by MCP clients (Claude Desktop, IDE integrations, etc.) — it isn't surfaced to the AI agent or the human using it. In practice, a user/agent who expected their project-local `mcpls.toml` to be loaded (e.g. one configuring per-tool routing per #228, or custom LSP servers) will see mcpls silently fall back to built-in heuristics with no visible indication why.
Expected Behavior
The "project-local config was ignored, pass --trust-project-config to opt in" notice should also be surfaced in-band, via a channel an MCP client/agent actually reads — most likely `ServerInfo.instructions` (`crates/mcpls-core/src/mcp/server.rs`, `McplsServer::get_info`), so an agent inspecting server info can notice and either report it to the user or pass the flag if authorized.
Actual Behavior
Only a `tracing::warn!` to stderr, generally invisible to the calling agent.
Notes
This requires threading "was a project-local config ignored" state from `ServerConfig::load_with_trust` through to `McplsServer::get_info`, which currently has zero coupling to config-load history — new plumbing with its own test story, which is why it was deferred out of #245 rather than bolted on right before merge.
Environment
Logs / Evidence
Flagged by the adversarial critique pass and confirmed by code review during #245: "stderr is swallowed by MCP clients, so agents get silent degradation of exactly the `./mcpls.toml` where #228's per-tool routing lives." Reviewer recommendation: file as P2 follow-up rather than block the #229 fix on it, since the security property itself is already closed and verified independently of this visibility gap.