Fix RUST_LOG=off requirement for MCP stdio transport

[Copilot]

This PR fixes an issue where MCP clients like VS Code and Gemini CLI would attempt to parse logging output as MCP protocol messages when using stdio transport, causing parsing errors.

Problem

When running wassette serve --stdio (or the default behavior), logging output was being mixed with MCP protocol JSON messages on stdout/stderr. This caused MCP clients to fail parsing messages like:

Failed to parse message: "\u001b[2m2025-08-04T00:51:15.148574Z\u001b[0m \u001b[32m INFO\u001b[0m \u001b[1mhandle_tools_list\u001b[0m..."

Previously, users had to manually add "RUST_LOG": "off" to their MCP client environment configuration as a workaround.

Solution

The fix moves logging initialization after CLI parsing to detect the transport mode and automatically:

• Defaults to RUST_LOG=off for stdio transport (both default and explicit --stdio)
• Preserves existing logging behavior for HTTP transport (--http)
• Allows RUST_LOG environment variable to override defaults when users need debugging

Verification

Before fix:

wassette serve --stdio  # Mixed log + JSON output

After fix:

wassette serve --stdio  # Clean JSON-only output
RUST_LOG=info wassette serve --stdio  # Logs available when needed

This ensures MCP clients receive clean JSON protocol messages without parsing interference, while maintaining full debugging capabilities when needed.

Fixes #73.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[Mossaka]

I think the bigger issue is that why is the parsing failed?

2025-08-03 20:51:15.149 [warning] Failed to parse message: "\u001b[2m2025-08-04T00:51:15.148574Z\u001b[0m \u001b[32m INFO\u001b[0m \u001b[1mhandle_tools_list\u001b[0m\u001b[2m:\u001b[0m\u001b[1mget_component_tools\u001b[0m\u001b[2m:\u001b[0m \u001b[2mmcp_server::components\u001b[0m\u001b[2m:\u001b[0m Found 2 components\n"

If we can fix that we don't have to default the LOG to be OFF, isn't it?

[thomastaylor312]

@Mossaka I think this was happening because stdio is using stdout/err. So when the caller receives a message, it isn't the response from a tool, it is the output of the logger. We should probably only log to file when in stdio mode. We can add this option to flags and config when #43 merges