Revisit committing a shared `.mcp.json` once Muse allows it

[hyochan]

Reminder so this workaround does not become permanent.

Context

18ea09e untracked the root .mcp.json (rationale in the commit comment): Claude Code expands ${VAR}, but Muse fails startup on any ${VAR} and offers no opt-out for project MCP files. Muse needs literal keys, which cannot be committed — so no single file content serves both tools. Each tool now uses its own user-level config instead.

Revisit trigger (either is enough)

• Muse supports ${VAR} expansion in project MCP files, or
• Muse gains an opt-out for project MCP files.

Action then

• Recommit a shared Claude-style .mcp.json with ${VAR} placeholders.
• Drop the .gitignore entry.
• Restore the Claude section in AGENTS.md to the project-scoped flow.

[hyochan]

Re-tested the revisit triggers against Muse 1.4.0 (1.4.0-R4161.1, current). Neither is met, so the workaround stays.

Trigger 1 (${VAR} expansion): not supported. Muse's own docs state it does not expand ${VAR}, and the 1.4.0 binary still carries the exact fault path from the field report (MCP configuration error in ...; MCP is disabled for this runtime). Recommitting the shared file would disable all MCP for every Muse session in this repo again.

Trigger 2 (opt-out): no project-MCP gating keys exist in Muse's settings surface (no projects/disabledMcpjsonServers equivalent). There is nothing to opt out with.

Two sidesteps also fail: Muse spawns stdio servers with only an allowlist environment plus the literal env map, so dropping the env block leaves the key empty; and the MCP endpoint rejects tool calls without the secret admin key, so a secretless shared file is useless.

Keeping this open. The one design that could serve both tools is a committed wrapper script that reads the key from a per-machine file (no ${} anywhere), but it needs interactive Muse verification before anyone commits it.