Osaurus Windows beta version 0.1.6: Auto-loaded MCP tools remain unavailable in the same turn; Manual works

Support Windows Beta
1

What happened?

With Tool selection = Auto, my custom agent discovers and loads MCP tools successfully, but then cannot call them during the same turn.

The tool trace shows inconsistent states:

  • capabilities_load reports that a tool is loaded and callable.
  • A subsequent capabilities_discover still says that the same tool must be loaded first.
  • Loading it again returns “already loaded and callable.”
  • The agent repeats discovery/loading and eventually stops without making the actual MCP calls.

In one affected conversation, sending a follow-up message allowed the previously loaded Microsoft Learn tools to work. Switching to Manual and explicitly listing the tools also allowed real MCP calls on the first turn.

Auto mode continued failing when tested again, including after terminating and relaunching Osaurus.

What did you expect to happen?

After capabilities_load succeeds, the loaded tools should be available to the model on its next step within the same turn, without another user message or switching to Manual.

This seems particularly relevant to the 0.1.6 release notes, which describe loading MCP/plugin tool definitions on demand in Auto mode to reduce token usage.

Steps to reproduce

  1. Configure a custom agent with tools enabled, Tool selection = Auto, and a connected Microsoft Learn MCP server:
    https://learn.microsoft.com/api/mcp
  2. Start a new conversation and request read-only tests of the configured MCP servers. For Microsoft Learn, ask it to search for official .NET CancellationToken documentation and fetch one result. Require actual MCP calls rather than shell or web-search substitutes.
  3. Observe successful capabilities_load results, followed by repeated discovery/loading and no actual MCP execution.
  4. In the affected conversation, send a follow-up asking it to continue using the Microsoft Learn tools already loaded. In my observed case, search and fetch then succeeded.
  5. As a comparison, change the agent to Manual, explicitly include the relevant tools, and repeat the task in a new conversation. Microsoft Learn search/fetch and Burp’s read-only project-options call worked immediately.

The Microsoft Learn tool names in my installation are:

microsoft-learn_microsoft_docs_search
microsoft-learn_microsoft_docs_fetch

Privacy Filter remained enabled during the successful Manual test. I have not isolated every possible privacy-filter interaction.

Environment

  • Osaurus version: Windows Beta 0.1.6.0, Microsoft Store, x64
  • Windows: Windows 11 Pro Insider Preview, 26H2, build 26340.9616
  • CPU / GPU / RAM: Intel Core Ultra 9 185H / Intel Arc integrated graphics / 32 GB
  • Model shown in chat: gpt-6-sol, through the ChatGPT/Codex connection
  • Agent: Custom agent, Osaurus-RE-Lab
  • Execution environment: Sandbox enabled; no workspace folder attached
  • MCP used for the clearest comparison: Microsoft Learn over HTTP

Logs / screenshots

The expanded tool trace shows:

  1. Successful loading of Microsoft Learn search/fetch schemas.
  2. Discovery subsequently describing those tools as requiring loading.
  3. A repeated load reporting that they are already loaded and callable.
  4. The agent stopping without actual MCP execution.
  5. Successful search/fetch after a follow-up message in the same conversation.
  6. Successful first-turn MCP execution in Manual mode.

For the successful follow-up, the UI recorded approximately 826 ms for search and 409 ms for fetch. The returned page was “Cancellation in Managed Threads.”

Additional technical evidence: static inspection of the installed assembly

I inspected Osaurus.ServerHosting.dll from the installed 0.1.6.0 package using ILSpy. The following appears consistent with the observed behavior:

  • CapabilityLoader.LoadTool / LoadGroup record loaded tool names through AgentPromptSessionStore.RecordLoaded.
  • CapabilityLoader.Load returns ToolOutcome.Ok(...) without setting InvalidatesRoster.
  • AgentToolLoop.ExecuteCallAsync returns that capability outcome directly.
  • The loop refreshes its tool surface when InvalidatesRoster causes rosterStale to become true.
  • ComposeRunSurface incorporates LoadedTools when constructing the tool list.

Possible cause: newly loaded tools are recorded in session state, but the active turn’s tool definitions and discovery scope are not refreshed. The next user turn reconstructs the surface and makes them available.

This is a static-analysis hypothesis supported by the UI trace; I have not captured the outbound provider requests or compared the 0.1.5 binary.

Assembly SHA-256:

E9BE25DDACDDF7A5F03166AFD6C72EBB0A8178219526A930AF6D820E263F0D18
2

I also reproduced the same Auto-mode failure with a workspace folder attached. It occurs both with and without an attached folder.

3

Thanks for the report.

4

This is not fixed in 0.1.7 with the same logic as 0.1.6

5

A fix was not attempted in 0.1.7. Should have it in the next release.

6

Should be fixed in 0.1.8