Skip to content

[Bug]: Configured MCP tools are hidden in Main and project chats by the ephemeral-turn filter #722

Description

@kazzand

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

  1. Configure and enable an MCP server in Settings; verify that Test succeeds and tools are discovered.
  2. Have at least one project registered in Ouroboros.
  3. In Main Chat, ask: "Check whether you can see the CodeAlive tools."
  4. Observe that the model cannot see any CodeAlive tool. A response may report mcp: ephemeral_turn and suggest sending another ordinary message.
  5. Open an existing project and ask the same question. Its chat also receives no MCP tools.
  6. 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

  • I searched existing issues and Discussions for this problem.
  • This report does not contain credentials, private data, or vulnerability details.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions