Repository navigation
[bug]: agent dynamic tool discovery fails with enable_mcp_without_auth() #115
Description
When an agent uses MCPToolBox for dynamic tool discovery, the tools are not created during load_component() they are discovered lazily at execution time via get_tools_async(). This call runs through the portal, where the _GLOBAL_ENABLED_MCP_WITHOUT_AUTH ContextVar has never been set, causing _validate_auth to raise.
Following a similar pattern to _ACTIVE_SPAN_STACK for _GLOBAL_ENABLED_MCP_WITHOUT_AUTH would resolve this.
Failure sequence
- Application calls enable_mcp_without_auth() [main async context]
- Application calls loader.load_component(agent) [main async context]
- MCPToolBox created, stores transport reference [no tool discovery yet]
- Agent conversation executes
- _collect_tools() → toolbox.get_tools_async()
- AsyncRuntime.call_async() → to_thread.run_sync() [worker thread, context copied]
- portal.call() [portal thread, SEPARATE context]
- get_server_tools_from_mcp_server() → MCPTool()
- _validate_auth() → _is_mcp_without_auth_enabled() [returns False — flag not set here]
- ValueError raised
Error output
ValueError: Using MCP servers without proper authentication is highly discouraged.
If you still want to use it, please call `enable_mcp_without_auth` before instantiating the MCPToolBox.
Activity
gotsysdba commentedon Mar 10, 2026
This is issue is a bit complicated... depending on the original intention.
If
_GLOBAL_ENABLED_MCP_WITHOUT_AUTHis meant to be a per-request toggle (as it is now), then a modification is needed to ensure it is propagated between two boundries to resolve the original error while dynamically discovering tools:call_async() → worker thread: to_thread.run_sync spawns a new thread — currently it resets to Falsecall() → portal task: portal.call dispatches into the BlockingPortal's background loop — a separate async context where it is again resets to FalseImplementing a fix for this allows multi-transport scenarios where one server needs auth and another doesn't; but does require the calling app to set
enable_mcp_without_auth()on each requestIf there was no intention to make this per-request but rather per-process, then changing
_GLOBAL_ENABLED_MCP_WITHOUT_AUTHfrom a ContextVar to a plain bool resolves the existing per-request boundry issues, eliminates the need for the calling app to setenable_mcp_without_auth()on each request but it breaks a auth/no-auth multi-transport scenario.Finally,
_GLOBAL_ENABLED_MCP_WITHOUT_AUTHcould potentially be changed to a per-transport flag where each transport carries its own settings allowing the auth/no-auth multi-transport scenario, no ContextVar or propagation issues; but this looks to be a much bigger change.gotsysdba commentedon Mar 18, 2026
Current workaround: instead of calling
enable_mcp_without_authbefore instantiating of the MCPToolBox, call before each execution.