Ouroboros version or commit
7.0.0-rc.7 (reported by the running desktop gateway).
Installation
macOS app
Environment
macOS 26.3.1, Apple Silicon. MCP client enabled; one CodeAlive server configured over Streamable HTTP. Its connection test succeeds and discovers 11 tools.
What happened?
A configured, healthy MCP server is unavailable to normal conversations in both Main Chat and a project's chat. The user asks to inspect CodeAlive, but Ouroboros says it cannot see the tools and suggests reconnecting or sending a new turn. Opening a project and restarting the app do not resolve the problem.
The tools are removed by Ouroboros before the request reaches the model. This is a mismatch between the tools shown as available in Settings and the capabilities usable from chat.
Reproduction steps
- Configure and enable an MCP server in Settings; verify that Test succeeds and tools are discovered.
- Have at least one project registered in Ouroboros.
- In Main Chat, ask: "Check whether you can see the CodeAlive tools."
- Observe that the model cannot see any CodeAlive tool. A response may report
mcp: ephemeral_turn and suggest sending another ordinary message.
- Open an existing project and ask the same question. Its chat also receives no MCP tools.
- Refresh MCP tools or restart the app and repeat. The restriction remains.
Expected behavior
A normal request to use an enabled MCP tool should be actionable from Main and project chats without requiring the user to understand the internal distinction between a chat turn and a managed task, or to use the special phrase "create a task."
Either expose the permitted tools in the conversation, or automatically route the requested operation through the existing managed-task path. If a tool is withheld, explain the actual execution-mode restriction and provide a working next action instead of suggesting that the healthy server is disconnected or that an ordinary next message will fix it.
Relevant evidence
POST /api/mcp/test for the configured server returned ok: true, tool_count: 11.
- Captured physical model requests from both Main and project chats contain exactly 18 built-in tools and zero MCP tools.
- Their context contains:
[CAPABILITY_OMISSION_MANIFEST]
- extensions: ephemeral_turn (no detail)
- mcp: ephemeral_turn (no detail)
- A captured request from a regular managed task on the same installation contains 113 tools, including all 11 CodeAlive tools, with
mcp_codealive__get_data_sources present. This verifies schema inclusion, not successful execution of that task.
- The failing project-chat request was sent through OpenRouter. The omission occurs before provider dispatch and is not caused by Praxis Relay.
Confirmed cause
In ouroboros/server_owner_routing.py, routing sets:
needs_decision_lane = swarm_intent or bool(project_id) or has_projects or bool(global_roots)
It then selects handle_chat_ephemeral whenever needs_decision_lane is true or the main agent is busy. Thus merely having a project, or chatting inside one, selects this restricted lane even when that project has no running task to receive the message.
ToolRegistry.schemas() in ouroboros/tools/registry_core.py omits the entire MCP surface when is_ephemeral_turn is true. _ephemeral_block_result() in ouroboros/tools/registry_guards.py also blocks MCP execution, so fixing schema visibility alone would be insufficient.
tests/test_ws5_carryover.py explicitly pins this blanket behavior in test_ephemeral_blocks_extension_and_mcp_tools and test_ephemeral_schemas_omit_extension_and_mcp_surfaces.
Validation for a fix
- Exercise both Main and an idle project's chat with an enabled MCP fixture.
- An ordinary request should complete a harmless MCP read without a manual mode-switching phrase; schema visibility and execution must agree.
- Cover a registered-but-idle project and a project with running work, since routing differs.
- Keep explicitly disabled tools excluded, and preserve the existing managed-task MCP path.
Related: #447. This is distinct from #660's resource/network filtering issue: the observed omission reason here is ephemeral_turn.
Before submitting
Ouroboros version or commit
7.0.0-rc.7 (reported by the running desktop gateway).
Installation
macOS app
Environment
macOS 26.3.1, Apple Silicon. MCP client enabled; one CodeAlive server configured over Streamable HTTP. Its connection test succeeds and discovers 11 tools.
What happened?
A configured, healthy MCP server is unavailable to normal conversations in both Main Chat and a project's chat. The user asks to inspect CodeAlive, but Ouroboros says it cannot see the tools and suggests reconnecting or sending a new turn. Opening a project and restarting the app do not resolve the problem.
The tools are removed by Ouroboros before the request reaches the model. This is a mismatch between the tools shown as available in Settings and the capabilities usable from chat.
Reproduction steps
mcp: ephemeral_turnand suggest sending another ordinary message.Expected behavior
A normal request to use an enabled MCP tool should be actionable from Main and project chats without requiring the user to understand the internal distinction between a chat turn and a managed task, or to use the special phrase "create a task."
Either expose the permitted tools in the conversation, or automatically route the requested operation through the existing managed-task path. If a tool is withheld, explain the actual execution-mode restriction and provide a working next action instead of suggesting that the healthy server is disconnected or that an ordinary next message will fix it.
Relevant evidence
POST /api/mcp/testfor the configured server returnedok: true,tool_count: 11.mcp_codealive__get_data_sourcespresent. This verifies schema inclusion, not successful execution of that task.Confirmed cause
In
ouroboros/server_owner_routing.py, routing sets:It then selects
handle_chat_ephemeralwheneverneeds_decision_laneis true or the main agent is busy. Thus merely having a project, or chatting inside one, selects this restricted lane even when that project has no running task to receive the message.ToolRegistry.schemas()inouroboros/tools/registry_core.pyomits the entire MCP surface whenis_ephemeral_turnis true._ephemeral_block_result()inouroboros/tools/registry_guards.pyalso blocks MCP execution, so fixing schema visibility alone would be insufficient.tests/test_ws5_carryover.pyexplicitly pins this blanket behavior intest_ephemeral_blocks_extension_and_mcp_toolsandtest_ephemeral_schemas_omit_extension_and_mcp_surfaces.Validation for a fix
Related: #447. This is distinct from #660's resource/network filtering issue: the observed omission reason here is
ephemeral_turn.Before submitting